The WikiData item for France (Q142) is very large. As a side effect, the constraints check via the special page for that item, https://www.wikidata.org/wiki/Special:ConstraintReport/Q142, results in a server error, most likely due to a timeout.
Acceptance criteria:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Stalled | PRODUCTION ERROR | None | T212282 Timeout in Special Page Constraints check for France (Q142) | ||
| Stalled | None | T204024 Store WikibaseQualityConstraint check data in persistent storage instead of in the cache | |||
| Open | None | T214362 RFC: Store WikibaseQualityConstraint check data in persistent storage | |||
| Open | None | T290961 rewrite KrBot to publish Constraint Violation pages | |||
| Open | None | T297096 add prefix `s:` or replace it with `wds:` |
So, I managed to make this page work https://www.wikidata.org/wiki/Special:ConstraintReport/Q142
But I also see:
2018-12-19T12:32:49 mw1252 WARNING Full constraint check on Q142 took longer than 55 second(s) (duration: 56.151183128357 seconds).
Which is pretty close to the timeout for a web request (I believe 60 seconds)...
Well, not really, I believe… the special page already doesn’t use cached results, and I think it should continue to be a way to request a full, fresh constraint check in the future as well.
It should probably start to used the cached checks, but provide a way to purge the check.
Are we logging this anywhere? Maybe the time these constraints checks take in general and the also items for which the checks take longer than $threshold.
Yes, these all appear in logstash.
EG: https://logstash.wikimedia.org/goto/f7ec3a5c71949b20e1b08a9a1b2f2325
(Example of task description is still reproducible.)
If it is feasible that no constraint checks are run on-demand, then I suppose the solution is to (after that) remove the access path to it. Replacing it an error message to the user and an application log message with warning or info level (severity depends on whether it is expected to sometimes still be possible).
However, if that is not likely to become reality soon, then perhaps it makes sense to acknowledge the current reality that for the common case of them not yet being precomputed, to set a very low self-imposed timeout (e.g. 2 seconds) and then bail out with a user-focussed error message (not an exception or application error log).
When a request is timing out, that is a sign of a problem in the software. The internal threshold should be far below 60 (not 55).
tldr; Yes we should and are going toward not having these run in the requests.
Constraint check runs are going to run post edit and be persistently stored.
T201150: Regularly run constraint checks for all items
T204024: Store WikibaseQualityConstraint check data in persistent storage instead of in the cache
This will mean most of these requests for constraint check data will just load from the store.
There will be some cases that the data stored is out of date and will need to be recalculated.
This is discussed in the current rfc @ T214362#4980932 and the few comments after that one.
The initial plan for those cases would be to keep the current behaviour (run the checks in the request, as well as trigger something to store some updated values for subsequent requests) however when we discuss this in the future there are other options such as don't show anything / say they are generating, do the checking in the job queue, save them, and then get the UI to poll & wait for them etc.
Removing from the campsite.
What we ideally want to do here is store constraint check data, and have the checks run post edit.
This is all tracked in other tickets.
This is blocked on:
T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage
T201150: Regularly run constraint checks for all items
T204024: Store WikibaseQualityConstraint check data in persistent storage instead of in the cache
Once persistent storage and checks in jobs is fully done we should no longer see timesouts