cache: strict cross-process gate for the warm session-cache refresh transaction#743
Draft
avs-io wants to merge 1 commit into
Draft
cache: strict cross-process gate for the warm session-cache refresh transaction#743avs-io wants to merge 1 commit into
avs-io wants to merge 1 commit into
Conversation
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
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.
Draft on purpose: per the commitment in #645, this stays a draft until you give the go-ahead — it's here so the code is reviewable whenever bandwidth exists, not to jump the queue.
Implements the revised design (third comment on #645): first slice, warm session-cache transaction only.
What changed
hydrating.lockis untouched — still cold-only, advisory, fail-open.src/cache-refresh-lock.ts: a strict cross-process gate (session-refresh.lock) around the warm read→reconcile→parse→save transaction. Four explicit outcomes:acquired,completed-by-other(reload the now-fresh cache),timed-out/unavailable(serve the prior complete snapshot read-only — a correctness lock never fails open into mutation). Exclusive-create + random ownership token, 10s heartbeat, 90s staleness with a takeover-guard sidecar that never steals a heartbeating owner, in-process single-flight ahead of the filesystem lock, monotonic-clock wait deadlines, bounded Windows EPERM/EBUSY retries.saveCachere-verifies ownership under the takeover guard immediately before the payload rename and aborts publication if displaced — a suspended/clock-jumped owner can no longer overwrite its successor's work.parseAllSessionsso timeout/stale serving performs no cache mutation at all.How tested
tests/cache-refresh-lock-process.test.tsis a real child-process lost-update regression — two warm processes parse disjoint changed files; with the lock wiring stashed it fails on stock code (later save drops the other's update), with the wiring it passes. Verified both directions locally.distbuilt (theapp/electron/cli.test.tsfresh-clone failures are app/electron/cli.test.ts fails on a fresh clone: dev-resolution tests require a built dist/cli.js #681, pre-existing).Follow-ups per the design: daily-cache cross-process transaction (lock order
daily → session), then #703's incremental parse runs inside this gate (draft PR opening alongside, stacked on this branch).