Waiter schedule forced and traced; field-level assertions (v0.3.2) - #27
Conversation
… field-level test assertions (v0.3.2) #23: a second gate (GIT_LOCKS_PAUSE_AFTER_READ) and a read trace (GIT_LOCKS_TRACE) force the waiter-with-stale-read schedule for both sem acquire --wait and with --wait, asserting exactly two reads. Forcing it found that after an invalidation each $(…) in the retry took its own snapshot, five per attempt; every read phase now loads once in the parent. #15: assertions on parsed fields in any key order; 51 substring checks converted. 300 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 (3)
📝 SummarySummary by CodeRabbit
WalkthroughThe release adds bounded snapshot reads, explicit refreshes across retry and read paths, read tracing and gate hooks, structured JSON assertions, and deterministic waiter tests for ChangesWaiter snapshot handling
Estimated code review effort: 3 (Moderate) | ~25 minutes Change: Bug fix · Severity of issue fixed: Medium Sequence Diagram(s)sequenceDiagram
participant Waiter as sem acquire --wait or with --wait
participant Snapshot as snapshot
participant Release as concurrent release
participant Store as lock store
Waiter->>Snapshot: read initial state
Release->>Store: release held state
Waiter->>Snapshot: read fresh state on next attempt
Waiter->>Store: acquire and continue
✨ 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 the snapshot twice Comment |
Closes #23 and #15. Forcing the schedule found and fixed five-reads-per-retry after an invalidation. 294 checks (the commit message says 300; this number is the run). Merging tags v0.3.2.