T185104 made me realize that there’s a race condition in our caching (T181060): it’s possible that a constraint statement is edited, but then a constraint check involving the edited constraint is performed and the results are stored in the cache before the constraintsTableUpdate job runs. The constraint check would still use the old version of the constraint, since the wbqc_constraints table wasn’t updated yet, but because validation of cached results currently uses the revision ID of the referenced property, the (actually stale) cached results would appear to be fresh even after the constraints table is updated.

One easy way around this problem would be to update the constraints table synchronously within the WikibaseChange hook handler, instead of only scheduling a job there which is then run asynchronously. This makes edits on properties which touch the constraint statements slightly slower, but I’m not sure if that’s a real problem: the job doesn’t do very much, anyways.

Can we see the average (or median, p99, whatever) runtime of the constraintsTableUpdate job somewhere? On the Grafana job-queue-health board, I can only see its wait time, which is also interesting for this task (the window for the race condition is about 15 s wide, apparently), but doesn’t help us when deciding whether we can afford to run the job synchronously.

Alternatively, T183159 might also solve this problem, because the information when a constraint statement was last edited would be updated together with the constraint itself.