Page MenuHomePhabricator

QuickStatements batch running in background stopped mid-way without user interference
Open, Needs TriagePublic

Description

Now that T232960 for "QuickStatements batch running in background not stopping with the stop button" is marked as resolved, I think a problem that I assumed to be related but is not resolved as of now needs its own ticket, so here we go:

Sometimes, a QuickStatements batch running in the background is stopping without me (or an admin) telling it to do so. A current example is batch 18726. When this happened in the past, the batch was usually resumed when I pressed the "Run" button again, but this does not work here.

Also, I think there were a few other similar cases recently, but since the interface only shows the most recent 20 batches and does not provide a way to browse past batches that have things like errors or "not done" edits, I have no easy way of finding such examples right now.

Screen Shot 2019-09-17 at 14.33.52.png (1×2 px, 582 KB)

Event Timeline

I am now running https://tools.wmflabs.org/quickstatements/#/batch/18806 as a replacement for https://tools.wmflabs.org/quickstatements/#/batch/18726 .

Not sure this is relevant for the current ticket, but since it may be, let me document some observations in relation to batch 18806.
After the first run, this resulted in " 100% (548) of 1914 done, 1366 errors".

Trying to reset the errors...
" 100% (939) of 1914 done, 975 errors"
Checking one of the affected papers with errors reveals that "anonymous" is stated as author (P50) twice: https://www.wikidata.org/w/index.php?title=Q29007934&oldid=1016438772#P50 .

Trying to reset the errors...
That gives " 100% (939) of 1914 done, 975 errors" again.
Gonna leave it at that for now.

Batch https://tools.wmflabs.org/quickstatements/#/batch/18811 also stopped (at " 82.2% (488) of 595 done, 1 errors") without manual interference.
Trying to reset errors...

This time, it ran through.