Acquisition id survives renewal; with releases by it (v0.3.1) - #22
Conversation
… (v0.3.1) 0.3.0 conflated the acquisition's identity with its record oid, so an extend inside a with changed the oid and the wrapper's release said "superseded", leaving the lock until expiry. Records carry an acquisition id now, minted by a claim and kept by extend and by the parent rewrite a child admission performs; release --acquisition, sem release --acquisition and with release by it, --record still matches an exact version. Reproduced first. Also a second forced interleaving (a renewal between a release's read and its commit), README wording that no longer implies the parent's liveness is re-checked at commit, and measured 500-lock timings. 286 checks.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (5)
📝 SummarySummary by CodeRabbit
WalkthroughThe lock system adds stable acquisition IDs separate from mutable record IDs. Claims, renewals, parent rewrites, releases, ChangesAcquisition identity lifecycle
Estimated code review effort: 3 (Moderate) | ~25 minutes Change: Bug fix · Severity of issue fixed: Medium Poem
✨ Finishing Touches📝 Generate docstrings
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. A rabbit reads each line, Comment |
Closes the second half of the review's MUST 4: claim_id distinct from record_oid. Reproduced first (extend inside with left the lock held), fixed, plus a second forced interleaving and honest timing numbers. Merging tags v0.3.1.