commit 8bbffd09e92a35644ac6d94f734e6ee93f532481
author Luca Milanesio <luca.milanesio@gmail.com> Fri Oct 31 15:56:56 2025 +0000
committer Luca Milanesio <luca.milanesio@gmail.com> Sat Nov 01 02:35:35 2025 -0700
tree 4b2aa6d4134cc6acfa4c50a7a4a5ecc0ec85905b
parent 5a79d0b70d3456b291775885d0e13e3a09e20546

Allow submission of changes when the index record is stale

The Gerrit change index is a way to find changes and is not guaranteed
to be aligned in real-time with the underlying change NoteDb status.

When a change index entry is stale, but the change is submittable,
Gerrit just executed a cycle of retries, hoping that the index would
become aligned within the retry period.

Introduce change.backfillMergeSuperSet for allowing the backfill
of change data from NoteDb when a stale change index is preventing
the submit to succeeed.
By default, the backfill does not happen and the submit is retried
multiple times, waiting for the change index be aligned.

By looking at the code, the change to be submitted is looked up in the
change index by project/branch/version-sha1, to obtain the same
ChangeData again from the index in the byCommitsOnBranchNotMerged()
method; whilst the need to look up changes by
project/branch/version-sha1 is mandatory for the dependent changes, it
isn't for the change to be merged.

When executing the logic to merge a change from the
completeWithoutTopic() path, the change-set to be merged is passed as
input parameter and therefore is already known. The use of the index to
find the same ChangeData from a potentially stale change index lookup is
unneeded and, in the best-case scenario, would result in returning the
same data that already exists in memory.

Use the input ChangeSet to backfill the set of changes to be
merged, so that if the change is found in the index, the looked-up entry
is still returned, but if that isn't present because of a stale index,
the merge can still be completed with the information already known.

The case of a temporary stale index is real and can happen in three
configurations:

1. Single Gerrit primary node, with index.indexChangesAsync=true
2. Gerrit HA with more than one Gerrit primary node, when the submit
   happens on the secondary node
3. Gerrit Multi-Site, where the submission happens on a different site
   compared to the one that has received the latest patch-set update.

NOTE: In case of 3, if the node executing the submission isn't
up-to-date with the global-refdb, the ref-update would fail anyway, so
it is still safe to try to execute the submit operation without the risk
to run into a split-brain situation.

Bug: Issue 456521736
Release-Notes: Avoid change N missing from ChangeSet[][] when submitting a change with a stale index entry
Change-Id: I61db3e2b4526be42e4c902ae6ee7e7b9e7bff809