https://bugzilla.wikimedia.org/show_bug.cgi?id=59678
Merlijn van Deen <valhallasw(a)arctus.nl> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |valhallasw(a)arctus.nl
--- Comment #6 from Merlijn van Deen <valhallasw(a)arctus.nl> ---
(In reply to John Mark Vandenberg from comment #4)
We have a changeset pending to overhaul token
management in site.py
https://gerrit.wikimedia.org/r/#/c/139372/
It adds caching of tokens so, with badtoken now appearing more regularly,
the cache needs better management of how long these tokens are useful for.
The entire problem is /caching/ the tokens. They are not valid for a fixed
time, they are valid of /one edit/. Basically it's a race condition, so there's
two options:
1) the 'nice' way: implement locking. Requires some sort of interprocess
communication,
2) the 'hacky' way: reduce the prevalence of the condition (by reducing the
time between getting a token and using it), and retrying -- effectively using
the remote MW instance as lock.
(In reply to Amir Ladsgroup from comment #5)
Maybe I'm wrong but edit conflict hasn't been
detected by tokens, it has
been detected by basetimestamp in mediawiki [1] and if edit conflict happens
it raises editconflict error not badtoken error. See the error table.
[1]:
https://www.mediawiki.org/wiki/API:Edit
Yes, you are right. So we can just implement this at the api.php level.
--
You are receiving this mail because:
You are the assignee for the bug.