In CachingResultsSource, we currently don’t cache serializations of NullResults. (I think it’s almost accidental – NullResult’s default status of TODO is not one of the cached statuses. This should probably be made more explicit either way.) This means that the wbcheckconstraints response for e. g. empty items is incomplete when it is cached:
{"wbcheckconstraints":[],"success":1}
It should be at least:
{"wbcheckconstraints":{"Q351":{"claims":{}}},"success":1}
In T185709: Cache CheckResult serializations per-entity in ObjectCache, I wrote:
One additional benefit is that we don’t need to cache the NullResults which we generate (cf. T178160), which should also save a lot of space in the cached value (given that we expect the average entity to yield few actual results that we would cache).
I think this is incorrect – we can’t reproduce those NullResults unless we know all the statement IDs of an entity, which would require loading it from the database, deserializing it etc., probably killing most of the benefits of caching. I think we need to actually serialize these NullResults and store them in the cache.
Setting priority to high, since this bug means users will see incomplete responses if we don’t fix this in time for the branch cut tomorrow.
- [serialize EntityContextCursor](https://gerrit.wikimedia.org/r/421904)
- [serialize NullResult](https://gerrit.wikimedia.org/r/421903)
- [DependencyMetadata fix in CheckingResultsBuilder](https://gerrit.wikimedia.org/r/421905) (semi-related)
- [handle NullResult in CachingResultsBuilder](https://gerrit.wikimedia.org/r/421906)
- minor refactoring