Wikimedia Bugzilla is closed!

Note that it is nowhere described how this new revert system should be used, whether the revert token retrieved by meta query is permanent, or if it changes for every revert.

Can you explain to me based on what you assessed this as low priority? It blocks the next release of huggle. Only solution for us is to revert back to deprecated method which may be removed entirely from MediaWiki, leaving no working option.

(In reply to Peter Bena from comment #1)
> whether the revert token retrieved by meta query is permanent, or if it
> changes for every revert.

A new token is not required for for every revert, although there's nothing stopping you from fetching a new token each time if you want.

The token returned will change each time you fetch one due to the new time-limited token functionality,[1] but at the moment any of the returned tokens should be valid until the session expires or something triggers a change to the token-secret in the session.

 [1]: https://lists.wikimedia.org/pipermail/wikitech-l/2014-October/079092.html


(In reply to Peter Bena from comment #2)
> Only solution for us is to revert back to
> deprecated method which may be removed entirely from MediaWiki, leaving no
> working option.

But you yourself state in comment 0 "and even if we fallback to previous method, the new token we get is also invalid". So how can you claim in comment 2 that you could use that method?


I've just submitted a few hundred rollbacks to enwiki that passed token validation (to avoid flooding sandbox history and the like, they were constructed to fail with code 'alreadyrolled' which is checked after token validation). 150 used the same session and the same token, while 300 used a new session with a newly-fetched token for each. You didn't specify when "peak hours" are, but I see "Reverted" around 11-14 times per minute in Special:RecentChanges at the moment and I'd think 1 out of 150 or 1 out of 300 would have failed if you're seeing 1 out of *20*.

It seems to me that it's more likely you've got something wrong in your code with respect to session cookie handling or the like.

(In reply to Peter Bena from comment #2)
> Can you explain to me based on what you assessed this as low priority?

Sure:

(In reply to Peter Bena from comment #0)
> This bug happens only when high traffic is on wiki, especially in peak
> hours when lot of vandals are being reverted (15+ reverts per minute). It
> can be reproduced only on wikimedia installation (for example english
> wikipedia) not custom mw installs, and it happens only rarely (1 from 20
> sessions).

(In reply to Brad Jorsch from comment #3)
> (In reply to Peter Bena from comment #1)
> > whether the revert token retrieved by meta query is permanent, or if it
> > changes for every revert.
> 
> A new token is not required for for every revert, although there's nothing
> stopping you from fetching a new token each time if you want.
> 
> The token returned will change each time you fetch one due to the new
> time-limited token functionality,[1] but at the moment any of the returned
> tokens should be valid until the session expires or something triggers a
> change to the token-secret in the session.
> 
>  [1]:
> https://lists.wikimedia.org/pipermail/wikitech-l/2014-October/079092.html
> 
> 
> (In reply to Peter Bena from comment #2)
> > Only solution for us is to revert back to
> > deprecated method which may be removed entirely from MediaWiki, leaving no
> > working option.
> 
> But you yourself state in comment 0 "and even if we fallback to previous
> method, the new token we get is also invalid". So how can you claim in
> comment 2 that you could use that method?
> 
> 
> I've just submitted a few hundred rollbacks to enwiki that passed token
> validation (to avoid flooding sandbox history and the like, they were
> constructed to fail with code 'alreadyrolled' which is checked after token
> validation). 150 used the same session and the same token, while 300 used a
> new session with a newly-fetched token for each. You didn't specify when
> "peak hours" are, but I see "Reverted" around 11-14 times per minute in
> Special:RecentChanges at the moment and I'd think 1 out of 150 or 1 out of
> 300 would have failed if you're seeing 1 out of *20*.
> 
> It seems to me that it's more likely you've got something wrong in your code
> with respect to session cookie handling or the like.

The code is open source, you are free to check it, but this used to work in past and now it doesn't. The queries were submitted just as I posted here. Maybe it would be more useful if mediawiki produced more descriptive error than "badtoken" which doesn't really say anything. According to documentation it should be valid. In same moment as when rollback token stop being valid, edit tokens are still valid. Isn't that weird?

How long is that rollback token timeout? And how often does it need to be refreshed? In order to reproduce this, you need to verify these basically whole day, checking this within a frame of 2 hours may not even trigger this bug. I always have to be "benchmarking" mediawiki whole day to get this error.

I tried to check most significant changes to api processing, and so far I got this https://github.com/huggle/huggle3-qt-lx/commit/93886156dd979767b6877b9e15ce5c62bc35be1f which I believe should not trigger this bug, but who knows...

I can no longer reproduce it, this bug will need to be resolved by x-files department of FBI.

Just as with UFO, there are people who have seen it. Have evidence. But nobody can explain it.

ok it started happening again, even for old huggle but only in PEAK hours where we had around 15 reverts per minute and after half an hour where traffic went down it started working. Note this can't be related to cookies etc because editing works in this bugged sessions. It's just not possible to rollback and requesting new rollback token doesn't help. Only fix is keep logging out and back until it works.

I believe this is caused by some caches like memcache or sql lags