Krinkle added a comment.
If it is feasible that no constraint checks are never 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
Addshore added a comment.
In T212282#4840637, @Michael wrote:
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/f7ec
Michael added a comment.
In T212282#4834025, @Addshore wrote:
[...]
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).
[...]
Are we logging this anywhere? Maybe the time these constraints checks t
Addshore added a comment.
In T212282#4840632, @Lucas_Werkmeister_WMDE wrote:
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 u
Lucas_Werkmeister_WMDE added a comment.
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.TASK DETAILhttps://phabricator.wikimedia.org/T212282EMAIL PREFERENCESh
Addshore added a comment.
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
