editgroups icon indicating copy to clipboard operation
editgroups copied to clipboard

Undo functionality is broken

Open wetneb opened this issue 1 year ago • 5 comments

Somehow, undoing batches on Wikidata no longer works. Under the hood, it looks like the reverts are attempted but fail without any logging message.

wetneb avatar Mar 07 '24 16:03 wetneb

@wetneb I understand from this that you do not plan to invest your time into this right now?

Right now, edit groups from the whole last week (last 6 days) do not seem to work.

As Edit Groups is an essential functionality of Wikidata, without no clear available replacement, maybe this should be reported to WMF? Or is there no maintainer whatsoever right now?

VojtechDostal avatar Mar 12 '24 11:03 VojtechDostal

@VojtechDostal thanks for chiming in! I didn't realize the batches of the past week were missing, so I have attempted to re-fetch them by restarting the edits listener. They should appear in the tool soon. I think that's a separate issue though, unrelated to the impossibility to undo batches which the tool already knows of.

It's unclear when I'll have to look into the problem of not being able to undo batches. I wouldn't want to weaponize this bug to force others to take care of this tool, but if people are interested in helping out, they'd be most welcome.

It also feels like a useful reminder that (in my opinion) EditGroups feels like a band-aid on a missing feature of MediaWiki. Implementing it as an external tool feels like a bad architecture to me, since it needs to maintain a parallel SQL database that can go stale easily. But implementing all of EditGroups' functionality in a MediaWiki extension seems also difficult, to handle long-running undo tasks. In the past we have been discussing this in this Phabricator ticket: https://phabricator.wikimedia.org/T203557

wetneb avatar Mar 12 '24 12:03 wetneb

Yeah, I agree it should be implemented in MediaWiki.

Thanks for the fix!

VojtechDostal avatar Mar 12 '24 12:03 VojtechDostal

The problem is likely coming from the fact that the redis instance is also used by others and so the communication between the web server and the tasks backend can get some interferences from other users of the redis instance (for instance, some which might take a task from the queue even if it's not intended for them).

The solution would likely be to add a global prefix to all redis keys that we use: it's a feature I requested 6 years ago, it was implemented but I haven't got round to introducing it in EditGroups yet https://stackoverflow.com/questions/50076885/custom-prefix-for-redis-keys-with-celery

wetneb avatar May 01 '24 07:05 wetneb

I've spent a bit more time debugging this and trying to fix it, but so far without success. I have written up about the state of the problem in https://phabricator.wikimedia.org/T203557 and https://www.wikidata.org/wiki/Wikidata_talk:Edit_groups#Not_working%3F.

wetneb avatar May 22 '24 17:05 wetneb

This was solved by switching to a different redis server (see https://www.wikidata.org/wiki/Wikidata_talk:Edit_groups#Not_working%3F)

wetneb avatar Jul 13 '24 14:07 wetneb