https://bugzilla.wikimedia.org/show_bug.cgi?id=59678
Merlijn van Deen valhallasw@arctus.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |valhallasw@arctus.nl
--- Comment #6 from Merlijn van Deen valhallasw@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.