https://bugzilla.wikimedia.org/show_bug.cgi?id=59678
Merlijn van Deen <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #6 from Merlijn van Deen <[email protected]> --- (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 on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
