After resolving a unique value violation by merging two items, the constraints gadget still shows a violation. Refreshing doesn't help, unless you wait a few minutes.
I assume this is caused by the target item being loaded after merging which loads (and caches) the constraint violations before the query service has had time to notice the merge.
The constraints extension itself doesn’t do any caching, but it looks like the query service caches the result of the “unique value” query.
We can easily break the cache – it looks like adding some rubbish URL parameter is already enough, even if the query text stays identical – but can we afford to lose all caching on these queries, or does that make “unique value” constraint checks too expensive?
Someone more qualified will have to comment on whether losing the caching would be a problem.
A couple of other ideas:
Add a short delay to the merge gadget before redirecting to the target item. I'm not sure how long the query service typically takes to notice merges (maybe we can measure it somehow?) but if all we need is a second or two, it might not be noticeably slower.
When we know we've just merged an item, check ask { wd:Q1234 owl:sameAs [] } to find out whether the merge has been processed by the query service. That could be in the merge gadget before redirecting or in the constraints gadget after redirecting (add a parameter to the URL or something so that it knows about the merge).
Add a short delay to the merge gadget before redirecting to the target item. I'm not sure how long the query service typically takes to notice merges (maybe we can measure it somehow?) but if all we need is a second or two, it might not be noticeably slower.
The problem isn’t that the query service doesn’t notice the change – the cache that sits before the query service returns the cached result without ever running the query. (As far as I know, there’s no cache invalidation on the query service.) Results are cached for five minutes, which is probably too long to delay the merge redirect for :)
When we know we've just merged an item
The checkConstraints gadget and the API don’t know that… but I guess we could introduce that special case: if there’s only one other item with the same value, check (in PHP, not via the query service) whether it’s a redirect to the current item or vice versa. If yes, assume the query service result is stale and don’t report a violation.
Can the constraint gadget know that it refers to a part of the data that has been changed in the last 5 min? If yes, it could show a more work-in-progress-like indicator until it is "sure" that the data is up-to-date.
We can determine that we got a cached result, but I don’t think we can find out if any related entities were edited since then. Do you think adding a disclaimer like this would be okay?
This report has been cached and might be slightly out of date.
Note: once the new build is deployed (today, tomorrow, or Thursday), we should see on Grafana how often query results are cached. That’s probably a very good thing to know before we make this decision (if, dunno, 80% of all results are cached, then showing this message is probably out of the question because it would be shown way too often).
With T179844, there is now a small message below the constraint violation indicating if the result is cached. I think that’s enough to resolve this issue, since it’s pretty easy to check manually whether the violation still exists or not if you’re unsure (the gadget shows you a list of other entities, check if those entities still have the same value).