[RSI, performance] Land the kernel skill-sync marker so killed sessions do not re-pay it - #2405
Conversation
Prime Agent performance — completedPR Overall: 0 regressed · 0 improved · 41 no clear change.
Python runtime
Session transport
UI interactions
Sandbox cost: ~$0.1605 — no inference calls. Methodology and samplesMain resolved at 2026-09-17T22:42:30.438198+00:00. Harness
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
27b432a to
be144c8
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit be144c8. Configure here.
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
378932c to
27b432a
Compare
The kernel Python bootstrap wrote its whole-version marker only once, after the last Python skill install. A session killed during the skill sync (short-lived benchmark sessions hit this every run) never recorded the marker, so the next startup wiped the venv and re-paid the runtime install plus every editable skill install. Write the marker atomically (temp file + rename, direct write fallback) and persist it incrementally: base fields right after the runtime install in bootstrapVenv, then the accumulated skill list after every successful install group in syncPythonSkills. A killed session now leaves a valid base marker so the next one takes the skills-only path and installs only the remainder, while the final unconditional write keeps the install-failure semantics (failed skills retry next startup) unchanged.
…arker writes The incremental marker write in syncPythonSkills persisted only the skills visited so far this session, so a completed install earlier in install order dropped skills already recorded in the marker but later in install order. A kill mid-sync then lost those skills from the marker, and the next startup re-ran their unchanged editable installs. Merge fresh entries into the on-disk marker for the incremental write; the final unconditional write stays an authoritative replace, and a missing or corrupt marker contributes no base entries. Adds a regression test that kills a child mid-install and asserts the marker keeps the already-recorded skills, and that resume skips their installs.
…wap fails The rename fallback overwrote the marker in place, so a failure or kill mid-write left a partial marker that reads as absent and forces a full venv rebuild. Retry the atomic swap a bounded number of times, then leave the previous marker alone and drop the temp file.
The SIGKILL/resume tests poll an external process (fake-uv log appends and OS pid liveness) with bounded deadlines and a generous per-test timeout, which the objective test policy flags. Mark each expression with a test-policy allow comment stating the specific external-process reason, following the precedent in mcp-connection-store.test.ts.
27b432a to
d02235e
Compare
… the test-line budget
…the compressed sync-marker coverage
… the compressed fail-probe test
…sed sync-marker coverage
2 participants
What
.bootstrap-versionmarker atomically (temp file + rename in the same dir, direct-write fallback) instead of one plain write at the very end of the skill sync.bootstrapVenvpersists the base marker (schema, runtime identity, snapshot, extra uv args) immediately after the runtime install, before the Python-skill sync.syncPythonSkillspersists the marker after every successfully installed skill group, so the marker always reflects completed work. The final unconditional write is kept, so install-failure semantics are unchanged: a failed skill warns, continues, and retries next startup; the warning is now exclusively for real install failures (marker-write failures propagate as bootstrap errors, like the final write on main).PRIME_AGENT_KERNEL_PYTHONoverrides, legacy-schema rebuilds, or the bootstrap dir-lock.Why
PR #2398's idle-RSS profile caught
uv pip install --editablere-running the bundled Python-skill sync inside the measurement window in 10/10 trials (~140 MB uv resident at idle). Root cause: the marker was written only once, after the LAST skill install, and no base marker existed before the skill sync - so any session killed mid-sync (the benchmark, and real short-lived sessions) recorded nothing. The next startup then failedkernelBaseReadyand took the full wipe path:rm -rfthe venv, re-install Python + prime-agent-runtime + extras, and re-run every editable skill install. Short-lived sessions re-pay this forever; the sync never converges.With this change, a killed session leaves a valid base marker plus the skills that already finished. The next session takes the skills-only path and installs only the remainder; once any session completes the sync, all later sessions hit the ready gate with zero uv invocations.
Local before/after
Same protocol as the benchmark harness: real uv 0.12.12, the real bundled release skills (11 with pyproject.toml), a uv shim logging every invocation, a throwaway venv, kill the process group mid-sync after 3 editable installs, then rerun to completion in a fresh process. All polls with explicit deadlines.
rm -rf+venv --seed+ runtime install)Cumulative short-session demo (one venv, 6 consecutive sessions killed mid-sync): on the branch the marker grows 2->4->6->8->10 skills across sessions, the venv is never rebuilt, the 6th session completes the sync, and later sessions run zero uv. On main every killed session wipes the venv and re-pays the whole bootstrap; the sync never converges.
The warm-cache wall-time delta is modest; the structural win (no venv wipe, no runtime+extras reinstall, only the missing skills) scales with cache-cold rebuild cost, which is the real-world regression the #2398 profile caught (~140 MB uv resident per session, 10/10 trials).
Testing
kernel-bootstrap.test.ts: 27/27 green (23 pre-existing + 4 new):npm run check(biome + tsgo + installer + browser-smoke) passes.Note
Medium Risk
Changes kernel bootstrap persistence and skill-sync failure handling on disk; incorrect marker logic could cause unnecessary venv rebuilds or stale skill manifests, though atomic writes and existing ready gates limit worst-case impact.
Overview
Fixes short-lived or killed sessions rebuilding the kernel venv and re-running the full Python skill sync because
.bootstrap-versionwas only written once at the end of sync (or could be truncated mid-write).bootstrap.tsnow lands a base marker (runtime identity, empty skill list) right after the runtime install and before editable skill sync. Each successful skill install triggerswriteMergedBootstrapVersion, which merges progress into the on-disk record; the final pass still does an authoritativewriteBootstrapVersion. Marker updates use write-temp + rename with bounded retries so a crash never leaves a corrupt partial file that looks “missing” and forces a wipe.Failed editable installs are not recorded (only appended after success); the loop continues so later skills can still install. Tests add fake-uv marker probes, a fail-path assertion, and a real SIGKILL mid-sync child process that proves the next startup skips completed skills and never runs
uv venvagain.Reviewed by Cursor Bugbot for commit f7b547a. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Write skill-sync marker atomically and incrementally in
bootstrapVenvwriteBootstrapVersionin bootstrap.ts now serializes to a temp file and renames into place, retrying 3 times with a 50 ms delay so the prior marker is preserved on total failure.writeMergedBootstrapVersionhelper merges existing marker skills with newly installed ones, allowing progress to persist across sync interruptions.bootstrapVenvwrites a base marker (empty skill list) right after runtime install and before Python skill sync, so a partially-synced venv is recognized as warm.syncPythonSkillsrecords each successful skill install incrementally and skips failed installs from the marker; the final write still replaces the full list authoritatively.Macroscope summarized f7b547a.
Test-line budget
This PR must pass the repo's test-line-budget gate (
node scripts/check-test-policy.mjs, run in CI): net added test lines may not exceed meaningful added source lines. Per the fleet-wide audit directive ("probably needs to remove redundant and unnecessary tests throughout. Remove unnecessary tests and we should have enough.") and the owner's follow-up ("nah dont grandfather them in. we should fix them now"), the branch compresses test lines by consolidation and removal of probe-verified duplicate coverage, with a lost-coverage ledger below.Lost-coverage ledger (executed cuts, probe-verified): this branch's ledger documents NO distinct vector loss — every cut is either a consolidation or duplicate scaffolding, and each surviving pin was verified by mutating the behavior it must catch:
deniedProbesparameter on the sharedwriteFakePythonhelper; every row asserts the identical error message as before.--seedfromuv venv) is kept together with this branch's durable-marker/atomic-swap coverage. The gate re-measured against the new merge-base (main tip fc9f2ae) is unchanged — net test additions 32 vs source 35, pass. The pre-existing "syncs a warm venv when a Python skill pyproject changes" deletion remains: its no-rebuild vector is pinned by this branch's kill test with a seed-agnostic assertion, and its stale-reinstall/fresh-hash vectors by the kill test's child pass and at-kill assert.