Ref rewinds observed in high traffic gerrit environments

[achakilam-nv]

Version

6.10

Operating System

Linux/Unix

Bug description

In a high traffic gerrit environment we are observing rare cases when refs get rewinded.

Actual behavior

In high traffic gerrit environment when multiple actions happen on a change, possibly a comment/vote and them submitting the change, We did see through our logs that meta ref did update to point to new commit created using submit strategy and then was rewinded to reflect the other meta ref update.

Expected behavior

Concurrent updates should either fail with a lock failure or should be applied in correct order.

Relevant log output

Other information

No response

[lucamilanesio]

The fix to this problem is fixing the unlocking during ref deletions. Did you verify that a deletion was involved in the refs' rewinding?

[lucamilanesio]

The fix to this problem is fixing the unlocking during ref deletions. Did you verify that a deletion was involved in the refs' rewinding?

I see that it wasn't any deletion of refs but simply the repacking of loose refs. Makes sense to me.

[achakilam-nv]

We've seen a recent case something like below.

#	Old OID	New OID	Note
1	A (null)	B (PS1 upload)	Initial creation
2	B (PS1 upload)	C (comment 1)	OK
3	C (comment 1)	D (comment 2)	OK — ref tip advances to D
4	C (comment 1)	E (PS2 upload)	❌ Stale old-OID; should have been rejected
5	D (comment 2)	F (comment 3)	Continues on overwritten chain