tree e1f5906c6eb971e7bbc666dfc82aff6432c4ac4f
parent 28f3e8b7bab9126b0ac5a30176fa7fc9ead1aa8d
author Luca Milanesio <luca.milanesio@gmail.com> 1694226010 +0100
committer Luca Milanesio <luca.milanesio@gmail.com> 1694464915 +0100

Fetch change version from refdb on Git protocol v2

The Git protocol v2 has a reduced refs advertisement
phase which is limited to the sole refs requested by
the client. The implications are that the change /meta
revision cannot be extracted anymore from the list of refs
passed to the filter.

Use a secondary lookup table based on the refdb, in order
to avoid caching a status or timestamp using only
the change-id.

Before this change, the Git protocol v1 was working as
expected, however, requests made using protocol v2 and
the only ref pointing to the patch-set were resulting
in serving stale data from the cache.

The cache key for the change open status and its
timestamp has the following three components:
- project
- change id
- change /meta revision

When the change /meta revision was not found in the
incoming list of refs to filter, the cache lookup
was made by simply project and change id.
The consequence were disastrous because an open change
was cached as being open and never invalidated, even
if later on it was abandoned or merged.

The fallback to a direct lookup into the refdb
would solve the problem, even though it may add an extra
lookup with a small performance penalty.

Add IT test with Git protocol v2 for verifing that the fix works
when the client would request a single patch-set ref to fetch.

Bug: Issue 299602346
Change-Id: I9018dee8de0570857d214935f8f4a32b47960ae0