Hallo Magnus, bitte sei sorgfältiger bei deinen Zuordnungen: Fahrenhorst (Q60203866) eine Ortschaft ist etwas anderes als ein Gutshaus, Feriengäste am Bollwerk (Q123243126) eine Skulptur etwas anderes als ein Gutshaus. Bitte korrigiere das. -- Gerd Fahrenhorst (Diskussion) 14:01, 9 July 2024 (UTC)
Magnus Manske
Joined 30 October 2012
und ja, eine Zementwerk ist auch kein Gutshaus: Q110240796 --Gerd Fahrenhorst (Diskussion) 14:03, 9 July 2024 (UTC)
Magst du mal antworten?
Nun atme erst mal tief durch, ich guck ja schon... :-)
Hi, shouldn't this one go in Q212164 instead? Q124024879 is only the chapel inside the fortress.
Fixed, thanks!
At least for Wikidata users who would be unpatrolled; preferably for everybody until it can be improved. See Wikidata:Administrators' noticeboard#Please revert June 20 edits by User:Jephtah Ogyefo Acquah for the latest problems, beyond what I can keep up with.
Deactivated until further notice
Over the past few months, the manual batch mode in QS has started to freeze regularly. When this happens, the current edit hangs in the "run" status and the batch just freezes indefinitely. This is bug #1. There is no connection between the jobs themselves - this can happen when adding any property statement or editing a label on an empty item.
Bug #2. When the above case happens - you can restart the queue by pressing STOP and RUN again. The task will be restarted, but the item on which the freeze occurred will remain in the "run" status forever. So after the batch is finished - these cannot be restarted in any way because they are not listed in errors and do not appear in "init" listing. The only way to track them is to manually search for "run" on each page, which is quite annoying for large batches. At the moment with 1k batches it happens about 10 times. And it seems like the only way is not to use manual mode or to run the batch twice in a row.
I suppose it would be great if at least the "Try to reset errors" button would also take into account those that remain in the "run" status.
I confirm experiencing both bugs, and I agree with Solidest that solving at least #2 (if possible, also #1) would be of great help. Thanks!
Hi all, just back from Covid now. #2 should be fixed (untested but seems trivial).
- 1 seems difficult to replicate; I'll look into it.
Glad you're back well, and sorry to bother you. But the fix has not helped. Tasks in "run" status are still not detected after clicking "Try to reset errors" and remain undone. UPD: It worked correctly in another browser. So maybe it just required clearing the cache.
And I suppose error #1 should not be that hard to reproduce. As it happens with every 200+ edits manual batch. For example, in https://editgroups.toolforge.org/b/QSv2T/1720448250160/ I had it triggered 6 times. Tried different batches on Chrome and Firefox, with and without VPN. No changes, it always happens at least once in ~100 edits (without fixed frequency - it could be three times in 30 edits, or could be 1 time in 200). Each time it was an instant response with a 502 error "Webservice is unreachable". And it is not marked with an error and retry is not done either, the queue just hangs.
I've just managed to reproduce the bug by repeating the same 100% completed batch - it still hangs and stops regularly. You could try running it as well: https://nopaste.net/egbIelbe9t
This seems to be caused by the webservice throwing 502 erros for some reason. I put an error mitigation in place, it will re-try 5 times with 2sec delay. Your example still throws 4 errors but they are of a different kind, and reset-able.
Thank you! Now the problem seems to be completely fixed. However, there is a small side effect that I have not seen before - it is rare errors occurring with the reason "Edit conflict. Could not patch the current revision." But they are handled by clicking "try to reset errors" at the end.
Hi Magnus, sorry to bother you, but I wanted to let you know that ListeriaBot is currently working inconsistently on the Hungarian Wikipedia. Based on the open issues on GitHub, it does not seem to be an isolated problem. Please see this page: although it should be updated daily, ListeriaBot fails most of the time. Unfortunately, I cannot tell you why this happens, as the bot status page does not work either. Would you mind taking a look? Thank you!
I know, working on it
Thank you!
- 2024-01-02 Topic:Xwhoclcgbbxoqste
- 2024-01-06 Topic:Xws6eqithns3eo9m
- 2024-02-07 Topic:Xyrhe7q69h2gxkno
- 2024-06-28 Topic:Y7jy3mwvfis8jbny
- 2024-06-29 Topic:Y7m62m1eyomucw7a
This should take care of the vast majotiry of cases.
Hi Magnus, ist das nicht eine genau wie burgenwelt.org ein External Identifier, den man statt "described at URL" verwenden kann?
Genau, bin nur noch nicht dazu gekommen, eine Property vorzuschlagen. Import läuft noch auf Mix'n'Match.
Greetings. I know that this has already been brought up many times. But would it probably be a compact solution to put a special value that changes the filled data to null? As here https://mix-n-match.toolforge.org/#/entry/41686689 I first added a value to the wrong property (inception instead of start time) and then tried to change it to 0, but it only got duplicated. And now if someone tries to create a Qitem from MnM, this junk data is also being added on WD. So it would be nice to set some value that could clear all data in the listed property when importing, something like %NULL%.