When a PatchListEntry is loaded, it is returned after its computation
and stored asynchronously in the cache. With I1e15767fc1, we modify
some edits after a PatchListEntry is loaded from the cache in
PatchScriptBuilder. Depending on the execution order, those
modifications could also end up in the persisted cache value, which
would lead to issues upon further requests.
In theory, we were already aware of this issue and fixed it for the
IntraLine diff cache in Ie7b44ae314. This change does something similar
for the PatchList cache.
The cache corruption could only happen in some specific situations. As
we index changes directly upon upload of a new patch set and that code
path computes the PatchListEntry without PatchScriptBuilder, the thus
generated cache entries are correct. They wouldn't be corrupted by later
calls which go through PatchScriptBuilder (any direct diff calls). If
however such a diff call happens first (e.g. different whitespace
setting) or in parallel to the index computation, the cache might get
corrupted. Further constellations are possible with a memory cache in
front of a persistent cache.
We invalidate the PatchList and IntraLine diff caches to get rid of
any potentially corrupt cache entries.
Bug: Issue 9464
Change-Id: If514aab8393eeced4fbb78bb9d646c7dd7a90a5a
f7a8462065