diag(daemon): name the cohort path that admits a mismatched build - #1474
Merged
Conversation
A forced client/daemon build mismatch raises a cohort conflict locally but is ADMITTED on every CI leg, which made the #1388 conflict regression untestable there. Reading the code explains how that is possible: identity comparison happens ONLY in the BUSY branch, i.e. when another process already holds the cohort lifetime lock. When the EX acquire succeeds - no live holder - the participant claims the cohort and NO comparison runs at all, so a mismatched build joins. That is correct behaviour when nothing is running. What is missing is the ability to tell the two apart after the fact: "was the lifetime lock held?" is exactly the question that separates the local run from the CI run, and no log line answered it. This is deliberately observability only - no admission behaviour changes. The next CI run that exercises the path will say which branch it took, and that decides whether the CI daemon simply is not holding the lease (an environment fact) or the lease is being released early (a real bug). Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
DeusData
enabled auto-merge
August 6, 2026 14:51
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Observability only — no admission behaviour changes.
Why
A forced client/daemon build mismatch raises a cohort conflict locally but is admitted on every CI leg, which is why the #1388 conflict regression could never bind there (it is now a documented local-only test).
Reading
cbm_version_cohort_acquireexplains how that is possible: identity comparison happens only in theBUSYbranch — when another process already holds the cohort lifetime lock. When theEXacquire succeeds (no live holder), the participant claims the cohort and no comparison runs at all, so a mismatched build joins.That is correct when nothing is running. What was missing is the ability to tell the two situations apart afterwards: "was the lifetime lock held?" is exactly what separates the local run from the CI run, and no log line answered it.
What this adds
One
version_cohort.claimed_unheldinfo line on the claim path, carrying the build fingerprint.The next CI run that exercises this will say which branch it took, which decides whether the CI daemon simply is not holding the lease (an environment fact, and the test stays local-only) or the lease is released early (a real bug worth its own fix). Shipping a behaviour change to a security-relevant admission path on a guess would be the wrong move.
Verification
version_cohort+daemon_version: 24 passed.lint-ciclean.