Repository navigation
Two reviewed ledger entries in the merge queue evict each other #5703
Description
🤖 Generated by the Agentic Engineer
Evidence
- On 1 November at 21:44 UTC, fix(supply-chain): replace the retired v7.23.0 publisher with v19.0.5 #5422 merged and fix(kyverno): raise the admission client rate limit #5693, queued right behind it, became DIRTY and left the merge queue. The only conflict was in
scripts/validate-eks-ci-role-policy/approved-surface-history.md: both PRs appended a section at the end of the file.approved-surface.txtmerged by itself. - Re-resolving it took about 20 minutes of CI and a fresh review, and fix(kyverno): raise the admission client rate limit #5693 went from position 2 to position 9. fix(kyverno): raise the admission client rate limit #5693 is the fix meant to stop the queue's Kyverno webhook evictions (Kyverno policy webhook timeouts evict healthy changes from the merge queue #5692).
- Read at 22:05 UTC: feat(gateway): receive PROXY traffic from the production load balancer #5696 (position 3), feat(storage): release the warm spare ahead of the Longhorn V2 worker #5698 (position 5) and fix(kyverno): raise the admission client rate limit #5693 (position 9) all edit this file. If they keep to the same pattern, the first to merge will drop the other two. This is an inference from fix(supply-chain): replace the retired v7.23.0 publisher with v19.0.5 #5422, not yet observed for these three.
- 14 commits changed this file since 18 October.
Audience / problem
Everyone waiting on the Platform merge queue. Any PR that moves a reviewed fingerprint must append to this file, so two such PRs in the queue conflict with each other even though their entries are independent.
Hypothesis
If the history file merges by keeping both sides (for example merge=union in .gitattributes), two independent ledger entries no longer conflict. approved-surface.txt stays under normal merging, so two PRs that change the same fingerprint still conflict and need a person or agent to look.
Not yet proven: whether GitHub's merge queue honours that attribute. The first slice has to measure this. If it does not, consider one file per entry, or a different way of recording the history.
Outcome and acceptance
- Two PRs that each append a history entry can both merge through the queue without either being dropped, shown on real PRs.
- Two PRs that change the same fingerprint line still conflict.
go test ./scripts/validate-eks-ci-role-policystill passes after such a merge, and neither entry is lost.
Reacted by coderabbitai
Activity
coderabbitai commentedon Nov 1, 2026
🔗 Related PRs
#5261 - feat(tenants): support verified source-only bootstrap [merged]
#5422 - fix(supply-chain): replace the retired v7.23.0 publisher with v19.0.5 [closed]
#5360 - refactor(policy): preserve Helm release defaults on CEL policies [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
chore: agent-claim #5703 nonce=8d04552e235ef85c01a57643b1ba4d99
Merge main; take main's frozen approval history (#5703)
Merge main; take main's frozen approval history (#5703)
devantler commentedon Nov 1, 2026
The premise here was wrong, and I am fixing a different cause. No PR has to append to this file. Its header has said since September that it is frozen and that approval evidence belongs in the pull request, for exactly this conflict reason. Nothing enforced that, so 20 commits appended anyway.
So #5704 enforces the freeze instead of adding a merge attribute. A union merge did work in a local test on #5696 and #5698, but it would have kept the appends going and was never needed.
Two things still stand: