RootSet retry misses structured update-ref lock races

[flyingrobots]

Problem

The v6.4.0 release-candidate verifier observed ExpiringSet concurrent safety fail with ROOT_SET_REF_UPDATE_FAILED. Immediate rerun and 12 focused real-Git repetitions passed, proving nondeterminism.

GitRefAdapter.updateRef() can receive a structured plumbing error with details.code: GIT_REPOSITORY_LOCKED when concurrent git update-ref --no-deref operations overlap at lock-file timing. RootSetPersistence.#isConflict() recognizes ordinary compare-and-swap stderr (but expected / reference already exists) but not this exact structured lock shape, so RootSet never executes its bounded conflict retry.

Required Fix

• Recognize GIT_REPOSITORY_LOCKED only when structured command arguments prove the failed operation was update-ref --no-deref for the exact managed RootSet ref.
• Preserve terminal behavior for unrelated repository locks and non-update-ref failures.
• Add deterministic unit coverage for both classification boundaries.
• Rerun the focused real-Git stress proof and full v6.4.0 release verifier.

Release Evidence

Blocks the v6.4.0 release candidate until fixed and reviewed.

[coderabbitai]

🔗 Related PRs

#21 - chore: prepare v5.3.3 ledger closeout [closed]
#66 - feat: add repository usage diagnostics [merged]
#67 - release: prepare git-cas v6.2.0 [merged]
#68 - docs: record git-cas v6.2.0 publication [merged]
#73 - release: prepare git-cas v6.3.0 [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 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:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[flyingrobots]

Release PR #78 carries the bounded-retry correction and v6.4.0 release evidence.

The classifier now treats GIT_REPOSITORY_LOCKED as a RootSet conflict only when structured command evidence exactly matches the five-argument update-ref --no-deref operation for the managed ref, new commit, and expected old OID. Malformed vectors and same-shaped locks for another ref remain ROOT_SET_REF_UPDATE_FAILED without falling through to text heuristics.

[cite: src/domain/services/RootSetPersistence.js#13-36@d1e126952d70007313a2ecd39bc7cffda06a9edd]
[cite: src/domain/services/RootSetPersistence.js#275-295@d1e126952d70007313a2ecd39bc7cffda06a9edd]
[cite: test/unit/domain/services/RootSetPersistence.test.js#150-193@d1e126952d70007313a2ecd39bc7cffda06a9edd]

Verification: focused RootSet tests 16/16, repeated real-Git ExpiringSet concurrency runs 20/20, and the complete release verifier 14/14 with 6,538 observed tests. This issue remains open until v6.4.0 publication evidence is attached.

[flyingrobots]

Fixed and published in @git-stunts/git-cas@6.4.0.

The retry classifier now accepts GIT_REPOSITORY_LOCKED only when structured command arguments exactly identify the managed update-ref --no-deref compare-and-swap operation. Other refs, malformed operands, altered OIDs, and unrelated lock failures remain terminal. Deterministic boundary tests and the complete release verification passed before publication.

[cite: src/domain/services/RootSetPersistence.js#8-36@b6cd2b3fbdc05dde6c0838e8d6e6e6737de6cf16]
[cite: src/domain/services/RootSetPersistence.js#275-295@b6cd2b3fbdc05dde6c0838e8d6e6e6737de6cf16]
[cite: test/unit/domain/services/RootSetPersistence.test.js#150-193@b6cd2b3fbdc05dde6c0838e8d6e6e6737de6cf16]
[cite: docs/design/0049-scoped-staging-workspaces/witness/release-publication.md#22-37@b6cd2b3fbdc05dde6c0838e8d6e6e6737de6cf16]