Speed up hosted and vendored scans: concurrent API requests, parallel crawl, single-pass rewriters

[Mikola Lysenko (mikolalysenko)]

Hosted and vendored scans spent most of their time in two places:

• waiting on HTTPS requests sent one at a time;
• per-ecosystem work that re-read, re-parsed and re-wrote the same files, plus an npm crawl that made one async round trip per filesystem call.

This PR makes the network phases concurrent and the crawlers and rewriters single-pass. It also adds lazy vendored sources, in-memory repacking and per-run parse memos, and ends with a small set of approved behavior changes.

Up to the approved batch, stdout, stderr, lockfiles, ledgers and exit codes are byte-identical to main. The approved changes are listed below and detailed in this comment.

Results

"Before" is main without this PR and "after" is this branch's head. Both use a replay proxy (recorded API responses served locally) at 100 ms/request, 2 interleaved reps, medians. Instructions retired are in parentheses.

The "before" binary predates #251–#254. #254 made cargo vendoring heavier, so the cargo rows understate the gain. Measured against the pre-batch head of this branch, cargo vendored fresh drops 49.6 → 38.9 G.

Target	Before	After
depscan scan --mode hosted --dry-run (live API)¹	18.3 s	4.1 s	4.5×
depscan hosted dry-run	17.1 s (17.9 G)	3.5 s (10.1 G)	4.9×
depscan hosted, real run (recorded latency)¹	35.8 s	7.5 s	4.8×
depscan vendored, fresh	46.3 s (28.8 G)	8.8 s (13.4 G)	5.3×
depscan vendored, idempotent re-run	16.3 s (28.9 G)	3.1 s (12.1 G)	5.3×
cargo (zed) hosted dry-run	36.4 s (204 G)	2.9 s (8.2 G)	12.6×
cargo vendored, fresh	63.5 s (66.8 G)	34.1 s (38.9 G)	1.9×
cargo vendored, re-run	20.7 s (50.0 G)	4.3 s (26.6 G)	4.8×
maven hosted dry-run	16.7 s (28.5 G)	2.8 s (3.3 G)	6.0×
maven vendored, fresh	61.5 s (55.1 G)	31.1 s (7.6 G)	2.0×
maven vendored, re-run	17.2 s (36.0 G)	3.1 s (5.1 G)	5.6×
nuget vendored, fresh / re-run	22.7 s / 7.0 s	11.8 s / 1.1 s	1.9× / 6.6×
composer vendored, re-run	8.0 s (7.2 G)	1.5 s (1.0 G)	5.4×
poetry hosted, real run	5.5 s (15.4 G)	1.4 s (4.5 G)	3.9×
uv hosted dry-run	4.2 s (15.1 G)	1.6 s (2.3 G)	2.7×
go hosted, real run	13.4 s	2.1 s	6.2×
strapi (yarn v1) hosted, real run, full clone¹	31.3 s	7.0 s	4.4×
187-project cross-ecosystem corpus, hosted / vendored¹	161.9 s / 136.0 s	111.7 s / 98.1 s	−31 % / −28 %

¹ Measured on the first slice of this PR and not re-run since.

• Byte equality (behavior-preserving part):
  • Every commit before the approved batch was A/B'd against the previous head.
  • The results were identical in all cases: stdout, stderr, the full project and home tree digest (locks, ledgers, vendored artifacts), the file list, and request counts. This held across 11 hosted/vendored fixtures and 9 ecosystems.
  • The integrated behavior-preserving tree was also identical to the original binary in all 35 steps × 2 reps.
• Request shape:
  • depscan hosted still sends 131 requests (56 batch + 74 by-package + 1 package-vendor), up to 8 in flight instead of 1.
  • Vendored fresh sends exactly main's 71 grants / 344 requests.
  • Cargo and uv send fewer requests only because of the approved deferred fetch (X1b).

What changed

Network (all ecosystems)

• utils/concurrent.rs is an ordered-concurrency helper (buffered, never buffer_unordered). Results, warnings and errors are folded in input order.
• By-package GETs, batch POSTs, hosted GET /patches/view, download views and vex record fetches run concurrently: 8 in flight on the API, 4 on the public proxy.
• The batch loop reproduces the proxy fallback exactly, at any chunk.
• The vendor prefetch plans downloads from each backend's own pre-flight gates, so it requests exactly what the serial loop will consume. Writes and wiring stay serial in record order, and the outage circuit breaker is replayed at consumption time.
• Lockfile-only packages are fetched concurrently.
• Telemetry is sent in the background and flushed before the next stdout write.
• New env var SOCKET_API_CONCURRENCY: 1 restores strictly serial requests. A tight descriptor limit falls back to serial automatically.

Crawl

• npm uses a parallel gather followed by an ordered single-threaded merge, checked against the old crawler kept as a randomized-equivalence oracle.
• The nine ecosystem crawlers run concurrently and merge in a fixed order.
• go, cargo, NuGet, site-packages and composer lookups run on one blocking task, with directory listings memoized only when complete.
• Maven POMs are parsed in parallel with bounded buffers.
• gem env and composer home are asked once per process.

Rewriters and vendoring

• Each lock is parsed once, indexed, and spliced in one pass. This covers pnpm (depscan 868 ms → 8 ms), npm, yarn classic/berry, bun, composer, uv/pylock/PEP 723, poetry/pdm, go.mod/go.sum and Cargo.lock (block search stops at the next [[package]]). The old rewriters are kept as oracles.
• Backend parse memos per run: Cargo.lock/config, composer.lock, packages.lock.json, the pypi locks, the JS lockfiles and the hatch ledger.
• Lazy vendored source: a fetched package is extracted only where something reads it.
• Zip members are inflated on a bounded pool, by name.
• Jars, nupkgs and wheels are rebuilt from memory. Digests are computed where the bytes are already verified.
• sha2 uses the aarch64 SHA-256 instructions.

Tooling: scripts/perf/ holds the record/replay benchmark harness.

Behavior changes (approved)

Details and measurements are in the batch comment.

• Ledger schema version 2 (X11): whole-file wiring snapshots (maven, nuget, pylock/PEP 723/hatch) are stored as {snapshot, ops} edits of the record's own original. Version 1 ledgers are still read and revert byte for byte. Other ledgers stay byte-identical v1. state.json shrinks: maven 29.8 → 15.1 MB, pylock 43.9 → 22.0 MB, nuget 7.2 → 3.9 MB.
• Deferred pristine fetch (X1b): a purl the ledger already covers, and a cargo crate the patch service serves, is not downloaded up front. An in-sync --offline / network-less re-run now succeeds (already_vendored, exit 0), and re-runs no longer report vendor_fetched_missing.
• -e <eco> crawl scope (MVN-4): without --prune/--sync, only the named ecosystems are crawled. lockfileOnlyPackages counts only them (depscan+zed -e npm: 6920 → 5347).
• Maven coordinates from the ~/.m2 path (MVN-1): canonical POMs are not opened once their top-level group directory is confirmed. A hand-placed POM that disagrees with its path reports the path's coordinates.
• Per-run group commit with journal replay (V2): lock/manifest/config/ledger edits are committed once per run through .socket/vendor/.commit-journal.json. A crash leaves the pre-run wiring, or is rolled forward by the next locked command. A failed commit write now fails the run with the new top-level error vendor_commit_failed (exit 1), replacing the per-purl vendor_state_write_failed / redirect_ledger_write_failed events; locks and ledgers stay pre-run, and artifacts written in the loop remain until the next run. vendor_stale_artifact_removed events now follow the per-package events.
• fsync policy (X12): vendored artifacts are written without a per-file fsync. One durability barrier runs before every durable commit point and at the end of the run, and lockfiles and ledgers stay durable.
• Caveat: the crash/journal and fsync semantics are covered by unit, failpoint and injection tests only, not by a live crash fixture.

Resolved: exact plan, 71 grants

The earlier prefetch planned download grants before each backend's pre-flight checks ran, so depscan sent 74 grant POSTs where main sends 71. The plan now calls each backend's own pre-flight gates, so fresh depscan vendoring sends exactly 71 grants and 344 requests, with 0 replay misses. Parity tests pin each npm flavor's plan against its loop, refusal for refusal.

Other observable differences

• With --debug, the [socket-patch debug] GET/POST <url> lines for concurrent requests interleave. Normal warnings keep serial order, and tests pin that.

Test plan

• cargo clippy --workspace --all-targets -- -D warnings is clean.
• cargo test --workspace --no-fail-fast: 9,218 passed, 0 failed, 136 ignored. No existing test was ignored or deleted. All existing test edits pin an approved behavior change: the two ledger-write-failure tests in covgap_commands_vendor.rs now expect the new vendor_commit_failed envelope error instead of a per-purl failed event (V2), and the redirect one no longer asserts that the artifact is absent, since it is written before the commit fails. It asserts instead that nothing is committed or rewired and no journal remains. The v1 legacy-ledger fixture for cargo was regenerated with the pre-batch binary to match main's Wire vendored cargo patches through Cargo.toml and tag the copy #254 cargo wiring. Every other change before the approved-behavior batch kept all existing assertions unchanged.
• New tests:
  • ordering under reversed latencies;
  • proxy fallback at any chunk;
  • telemetry flush;
  • crawler, rewriter and lazy-source equivalence against oracles;
  • plan-vs-loop parity for every npm flavor;
  • SOCKET_API_CONCURRENCY=1 and tight fds;
  • failpoint crash tests at the durability barrier and inside the group commit;
  • journal replay, set-aside and restore-failure paths;
  • ledger v1 ↔ v2 round trips for every ecosystem.
• Every commit went through adversarial review for behavior equivalence, concurrency and test integrity. Each finding was fixed or refuted with evidence.
• A/B benchmarks with byte-equality checks for every batch, as above and in the batch comments.

The commits are the original reviewed commits, replayed onto current main (#251–#254). Where a conflict or an adaptation to main was needed, it is folded into the commit that needed it, and each batch comment lists them.

🤖 Generated with Claude Code

---

Note

High Risk
Changes vendoring crash semantics, ledger schema, offline/idempotent vendor behavior, Maven discovery coordinates, and concurrent API failure modes—areas that affect committed project state and patch correctness.

Overview
This PR speeds up hosted and vendored workflows by running patch-API traffic concurrently (default 8 authenticated / 4 on the public proxy) via ordered_concurrent, with SOCKET_API_CONCURRENCY (1–32) to throttle when a proxy or WAF limits in-flight requests. The same pacing applies to vex / scan --vex record fetches and hosted wheel-metadata downloads; hold_back_debug keeps per-request --debug lines in the same order as the old serial loop.

Beyond networking, it lands several v5.0 contract changes documented in CHANGELOG / CLI_CONTRACT: deferred pristine fetch so already-vendored / service-backed cargo re-runs can succeed offline without upfront registry pulls; scan -e crawls only selected ecosystems (except prune/sync); Maven derives coordinates from canonical ~/.m2 paths when the repo root is confirmed; vendor ledger v2 stores large whole-file wiring as snapshot+ops edits; one group commit per vendored run through .socket/vendor/.commit-journal.json (new top-level vendor_commit_failed on commit I/O failure); and batched fsync for artifacts before durable lockfile/ledger writes.

Smaller fixes include vex api_auth_fallback quoting the first refusal in pending order (not completion order), batched gem/Python stale-install probes using judge_installed_record, and confirm_waits so scan knows when a hosted confirm prompt will block.

^{Reviewed by Cursor Bugbot for commit f9fc676. Configure here.}

[Mikola Lysenko (mikolalysenko)]

⚠️ Behavior changes (approved)

Pushed 57a0d0c..5916139 (29 commits). Everything before this push kept output byte-identical to main. These commits change observable behavior on purpose; each change was approved before it was built. They come from perf/bcA (MVN-1, MVN-4) and perf/bcB (X1b, X12, V2, X11), replayed with messages and authorship kept. None were dropped.

What a user or consumer sees differently

1. .socket/vendor/state.json schema version 2 (X11). A ledger that holds whole-file wiring snapshots is now written as "version": 2. That covers maven pom.xml, nuget.config, pylock/PEP 723/hatch documents, and only records of 1 KiB or more. Each such record's new is stored as {"snapshot": "<sha256>", "ops": [...]}, an edit of the same record's plain-text original. Nothing is stored outside the entries.
   • Version 1 ledgers are still read, and still revert byte for byte. This is pinned against ledgers checked in from the previous binary.
   • Ledgers with no whole-file records (cargo, go, gem, composer, poetry, uv, npm/pnpm) stay byte-identical version 1.
   • A tool that parses state.json itself and reads wiring[].new as a string must handle the object form. No known consumer outside socket-patch reads it.
   • An edit that does not reproduce its hash is vendor_state_unreadable.
   • Records are self-contained, so an older CLI that re-saves a v2 ledger loses nothing. On a v2 record, that CLI leaves the fragment alone and prints its drift warning.
2. Offline re-runs succeed (X1b). Before, a purl with no installed copy always had its pristine artifact downloaded before the backend ran. The download now waits until something reads the pristine tree, and is skipped when the vendor ledger already covers the purl or a cargo crate is served by the patch service.
   • An in-sync vendor --offline (or network-less) re-run of an already-vendored pypi/cargo/go/lockfile-only-gem project now exits 0 with already_vendored. Before, it failed with package_not_installed / partialFailure.
   • Events are now reported in loop order.
3. vendor_fetched_missing warnings are gone from re-runs (X1b). An idempotent re-run makes no registry requests for covered purls and no longer reports vendor_fetched_missing.
   • A deferred fetch that does happen (a drifted copy being rebuilt, a service miss) reports its warning just ahead of that package's own event.
   • Under --vendor-source build, a not-installed gem the lock can verify but no ledger covers is refused gem_spec_missing before download.
4. scan -e <eco> crawls only the named ecosystems unless --prune/--sync (MVN-4). lockfileOnlyPackages and the human "not yet installed" note now count only the selected ecosystems. scannedPackages already did. A GC run still crawls everything and is unchanged.
5. Maven coordinates come from the ~/.m2 path (MVN-1). A POM at its canonical <group>/<artifact>/<version>/<artifact>-<version>.pom path is not opened. Each top-level group directory is first confirmed against one POM that parses, so a MAVEN_REPO_LOCAL pointed above or inside the repository still reads content-first. Under a confirmed directory, a hand-placed POM whose contents disagree with its path now reports the path's coordinates.
6. Crash semantics are now per run, with journal replay (V2). vendor, scan --mode vendored and get --mode vendored capture every lockfile/manifest/config edit and ledger save in memory, then commit them once after the loop through .socket/vendor/.commit-journal.json.
   • A crash mid-loop leaves the pre-run wiring, not the packages done so far.
   • A crash mid-commit is rolled forward (or back, around hand edits) by the next locked command.
   • A journal that cannot be trusted is set aside as .commit-journal.set-aside-<uuid>.json, and nothing is applied.
   • New top-level error vendor_commit_failed (exit 1). If the final commit cannot write a lockfile, manifest or ledger, the run now fails with this envelope error. Before, a ledger or redirect-ledger write failure was reported as a per-purl failed event (vendor_state_write_failed / redirect_ledger_write_failed). Locks and ledgers stay at their pre-run state, but artifacts written during the loop are left on disk until the next run cleans them up.
   • vendor_stale_artifact_removed events now come after the run's per-package events, because stale artifacts are removed after the commit.
   • Two existing tests in covgap_commands_vendor.rs were updated to pin this: vendor_state_write_failure_reports_failed_event and redirect_ledger_write_failure_fails_takeover_purl_closed, now renamed redirect_ledger_write_failure_commits_nothing. Their per-purl failed assertions became vendor_commit_failed checks. The redirect test's "tgz must not exist" assertion became "no ledger is committed, the lock is not rewired, and no journal is left behind", because the artifact is now written before the commit fails.
7. fsync policy (X12). Content-verified artifacts under .socket/vendor/<eco>/<uuid>/ are written atomically but without a per-file fsync. One barrier (file + dir fsync, one F_FULLFSYNC per device on macOS) runs ahead of every durable commit point, at the end of the group commit, and when the apply lock is released. Lockfiles, manifests, configs and ledgers stay durable. A lost artifact byte is caught by the next run's hash re-verification and rebuilt.

Caveat: the crash, commit-failure and journal-replay semantics (6) and the fsync policy (7) are covered by unit, failpoint and injection tests only, not by a live crash or power-loss fixture. No benchmark below can reach those paths.

Integration with main (#251–#254)

• Text conflicts: CHANGELOG [Unreleased] (kept bcA's entries, then bcB's) and three CLI_CONTRACT lines, where bcB's additions were merged onto Fix Windows (yarn berry CRLF support) and first-run real-PM CI failures after #251 #253/Wire vendored cargo patches through Cargo.toml and tag the copy #254's GOPROXY text.
• Adaptations to Wire vendored cargo patches through Cargo.toml and tag the copy #254 (cargo wiring moved into Cargo.toml, tagged copies). Each is folded into the commit that needed it:
  • 0f453cea group commit: Wire vendored cargo patches through Cargo.toml and tag the copy #254's migration deletes a socket-created .cargo/config.toml inside the vendored run. The deletion is captured, so pruning .cargo/ immediately found the file still there and left a husk. .cargo/ is now removed after the commit, only if empty; the same applies to the staged hosted-redirect revert. A unit test covers abandoned, successful, non-empty and no-group cases.
  • 337bf557 artifact durability: Wire vendored cargo patches through Cargo.toml and tag the copy #254 tags the copy's Cargo.toml with a durable write. It is a content-verified artifact, and the durable write fired the barrier inside the stage, so it now uses a mode-preserving artifact write. The cargo crash test asserts the new Cargo.toml wiring instead of .cargo/config.toml.
  • 48528e78 ledger v2: the cargo legacy-ledger fixture was regenerated with the pre-batch binary (57a0d0c), because Wire vendored cargo patches through Cargo.toml and tag the copy #254 changed cargo's wiring files. The other nine ecosystems regenerated byte-identical.
• Tree check: per file, diff(39ba93a3, HEAD) equals diff(827d981f, 57a0d0c0) on every changed line. The only exceptions are the 11 files carrying the resolutions above. Batch 4 already showed that diff equals diff(bb54e9bb, origin/main) modulo its documented resolutions.

Tests

clippy --workspace --all-targets -D warnings is clean. cargo test --workspace --no-fail-fast: 9,218 passed, 0 failed, 136 ignored (57a0d0c had 9,146).

A/B

Setup: b4 = 57a0d0c, b5 = 5916139. Replay proxy at 100 ms/request, 2 reps with rotated order, medians. Instructions retired, wall time in parentheses.

case	b4	b5	approved item
maven hosted dry	8.36 G (3.02 s)	3.31 G (2.77 s)	MVN-1
maven hosted wet	8.42 G	3.51 G	MVN-1
maven scan --mode hosted --dry-run -e npm	7.00 G (0.69 s)	0.04 G (0.11 s)	MVN-4
maven vendored fresh	32.4 G (38.6 s), RSS 1,070 MB	7.6 G (31.1 s), RSS 279 MB	MVN-1 + X11
maven vendored re-run	10.2 G	5.1 G	MVN-1
nuget fx-scale vendored fresh	15.2 G, RSS 266 MB	8.6 G, RSS 105 MB	X11 + V2
nuget fx-real vendored fresh	2.76 G	2.12 G	X11 + V2
pylock (12 patches) vendored fresh	17.1 G (3.9 s), RSS 500 MB	13.6 G (2.3 s), RSS 409 MB	X11 + V2
cargo zed vendored fresh	49.6 G (40.0 s), 492 requests	38.9 G (34.1 s), 456 requests	X1b
cargo zed vendored re-run	26.5 G (5.2 s), 162 requests	26.6 G (4.3 s), 126 requests	X1b
cargo zed vendor --offline re-run	exit 1 (17.9 G)	exit 0 (26.9 G: the 36 in-sync checks now run instead of refusing early)	X1b
uv-big vendored re-run	3.04 G (1.60 s), 28 requests	0.89 G (0.73 s), 17 requests	X1b
uv-big vendor --offline re-run	exit 1	exit 0	X1b
depscan vendored fresh	14.9 G (9.7 s)	13.4 G (8.8 s)	V2 / X12
depscan vendored re-run	11.6 G	12.1 G (same 131 requests, same output; within this fixture's spread)	—

state.json size:

fixture	b4 (v1)	b5
maven	29,843,313	15,065,386 (v2)
pylock	43,896,582	21,964,210 (v2)
nuget fx-scale	7,221,990	3,873,321 (v2)
nuget fx-real	743,209	449,784 (v2)
cargo, go, gem, composer, poetry, uv, depscan pnpm	—	unchanged, byte-identical v1

Every observed difference, and the approved item it maps to

54 steps × 2 binaries × 2 reps. The checks: canonical stdout, stderr, full project and home tree digest, file list, and request/grant counts.

• cargo-v fresh/re-run (X1b). b4 emits 36 vendor_fetched_missing and makes 36 more registry GETs. Dropping those events, stdout is identical, and so are the tree and ledger.
• uv-v re-run (X1b). 11 vendor_fetched_missing and 11 GETs are gone. Otherwise identical.
• cargo-v / uv-v --offline re-run (X1b).
  • cargo: partialFailure, 36 package_not_installed + 74 already_vendored becomes success, 110 already_vendored.
  • uv: 11 + 1 becomes 12 already_vendored.
  • The tree is identical in both.
• ds-cargo-enpm scan -e npm (MVN-4). lockfileOnlyPackages goes 6920 → 5347; nothing else changes. With --prune the output is byte-identical (6920).
• maven-v, nuget-v, nuget-scale-v, pylock-v, every step (X11). .socket/vendor/state.json is the only differing file. Decoding the v2 ops and masking vendoredAt, it equals b4's ledger in all 24 comparisons. Every lock, manifest, config and artifact is byte-identical.
• MVN-1, V2, X12. No output difference on any run, and no .commit-journal* remains in any tree.

Byte-identical on both binaries (stdout, stderr, tree, file list, requests):

• Hosted, dry and wet: depscan (real tree, plain and -e npm), cargo, maven, nuget, composer, uv, poetry, go, gem.
• Vendored, fresh / re-run / offline: depscan, composer, poetry, go, gem.
• uv vendored fresh.

Nothing differs that is not listed above.

🤖 Generated with Claude Code

Edited after review: added the vendor_commit_failed error, the event-order change, and the two updated tests under item 6.

[Mikola Lysenko (mikolalysenko)]

CI fixes for the 17 failing checks on 5916139

I pulled the logs for every failing check. They come down to four root causes, and fixing the first one exposed three more Windows-only failures that it had been hiding. Commits pushed as fast-forwards: 6dbbf0eb, bfbc088e, 76c90e9f, ed120d8c, f9fc6765.

1. Windows: Access is denied. (os error 5) on every vendored run

Checks: 13x native (windows-latest, *), binary (windows-latest), most of test (windows-latest) (29 test binaries)

Root cause: the durability barrier (utils::durability::sync_all_blocking) reopened every deferred artifact by path with File::open, which is read-only, and then called sync_all. On Windows, FlushFileBuffers needs a handle with write access, so the call fails with ERROR_ACCESS_DENIED. That made the group commit refuse ("could not commit the vendored lockfile, manifest and ledger edits") and the lock release warn "could not sync the vendored artifacts". Directory syncs were not the problem: they were already Unix-only. Reopening for write would not help either, because Windows refuses a write open on a read-only artifact.

Fix (6dbbf0eb): off Unix, stage_and_rename fsyncs every stage through its own writable handle before the rename. That is what the durable writer, and main, always did there. The barrier then has no files left to sync (DEFERS_FILE_SYNC = cfg!(unix)). Artifacts are still recorded, so the barrier and its durability_barrier failpoint run at the same points on every platform. Unix keeps the deferred plain-fsync barrier unchanged.

2. test-release: the crash-safety suites could not crash

Root cause: this was not a timeout. The job failed after 34 minutes in vendor_crash_safety_e2e with "the failpoint must crash the run". SOCKET_PATCH_FAILPOINT was compiled in under debug_assertions only, so in the optimized ci-release test binary the failpoint did nothing and the run finished with status success. vendor_group_commit_e2e would have failed the same way. The job has no --no-fail-fast, so it never got that far.

Fix (bfbc088e): a new socket-patch-core feature, failpoints, compiles the failpoints into non-debug builds. The CLI enables it only from [dev-dependencies], so resolver 2 adds it to cargo test builds, debug or release. cargo tree -e normal,features confirms it never reaches cargo build --release or cargo install, so a shipped binary still has no exit you can trigger from an environment variable. Both suites pass locally under --profile ci-release.

3. CodeQL: 5 new high rust/cleartext-logging alerts

Root cause: four prefetch-plan cross-checks put the patch uuid into their unreachable debug_assert! messages (fetch_stage.rs, get.rs ×2, scan/discovery.rs). Separately, debug_log's refactor for deferred lines moved its eprintln! to a new line, and CodeQL treated main's existing alert #48 there as a new one.

Fix (76c90e9f): the assert messages now name the plan that fell out of step instead of the uuid. debug_log keeps main's direct eprintln!, and the deferral moved into a separate defer_debug_line function. Nothing was dismissed. CodeQL now reports "No new alerts in code changed by this pull request".

4. Windows-only test failures exposed once #1 was fixed

• vendor_ledger_schema_e2e: the checked-in tests/fixtures/legacy-ledgers/** files were converted to CRLF by the Windows autocrlf checkout. They are now -text in .gitattributes, the same treatment as the redirect and pnpm golden fixtures (ed120d8c).
• vendor_ledger_schema_e2e (pypi-requirements wheel hash, nuget contentHash): a real cross-platform determinism bug. zip 8 stamps the central directory's "version made by" host as DOS on a Windows build. So write_zip_entries produced different bytes on Windows than on Unix, even though it promises byte-identical archives, and it also told readers to ignore the unix modes it carries (the preserved exec bit). It now pins System::Unix, as does the fixtures' zip builder. A new unit test pins the host byte and the modes (f9fc6765). Every product wheel, jar and nupkg rebuild goes through write_zip_entries. On Unix the bytes are unchanged.
• go_crawler randomized_caches_match_the_async_oracle: the non-vacuity bar failed at 92/80 on Windows, where case-insensitive names fold together and file modes are ignored. The bar is still >100/>100. The test now adds seeds until the fixtures clear it (at least 48, at most 480) (ed120d8c).
• registry_fetch parallel_zip_extraction_matches_the_in_order_reader: the test helper tree_of reported backslash paths and mode 0 off Unix, while the oracle used / and Unix modes. The paths are now normalized, and the oracle expects mode 0 where the disk stores no mode (ed120d8c).

External flakes (re-ran the failed jobs; no code change)

• native (ubuntu-latest, 1.1.39), and native (macos-latest, 1.1.39 / 1.1.45) on the next run: the production API returned 503: upstream connect error or disconnect/reset before headers. reset reason: connection termination, as shown in the cells' repeat.log / cli.log.
• native (macos-latest, 1.0.0): bun 1.0.0 IntegrityCheckFailed extracting tarball for minimist, once. The same cell passed on 76c90e9, and the binary code was identical between the two runs.
• On f9fc676, native (ubuntu-latest, 1.4.0 / 0.8.1) hit the same production API 503/504 (API request failed with status 504: error code: 504 and the 503 above). 1.4.0 hit it a second time on its first re-run, in a different cell.
• Every one of these passed on re-run.

Verification

• Local macOS: cargo clippy --workspace --all-features -D warnings clean. The full cargo test --workspace --no-fail-fast passed (262 binaries) after each iteration. The failpoint suites also pass under --profile ci-release.
• Not done: cargo check --target x86_64-pc-windows-gnu, because this machine has no mingw C toolchain. Windows was verified on CI.

Final CI state on f9fc6765: all 407 checks green. That includes CodeQL, test (windows-latest), test-release, binary (windows-latest) and every native (windows-latest, *) cell.

🤖 Generated with Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

[Mikola Lysenko (mikolalysenko)]

Claude (@claude) review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit f9fc676. Configure here.}

[Mikola Lysenko (mikolalysenko)]

External validation (depscan cross-OS Maven matrix): depscan's harness ran its full 25-job Linux/Windows/macOS Maven matrix against this PR's head f9fc6765, with real mvn 3.9.16 (run 36265269179). It found no Maven regressions: every job passed.

It also confirms that this PR fixes #275, the pre-existing Windows zip-host bug. All 55 vendored local-rebuild cells now produce identical jar digests on Linux, Windows and macOS. On main, the Windows jars differ.

🤖 Generated with Claude Code

[Mikola Lysenko (mikolalysenko)]

WP-P1: vendored CPU memos (11 commits, f9fc676..cfeafb0)

• SC1: reuse::prior_entry answers the reuse anchor from the run's shared ledger parse (load_state_shared) and no longer re-parses the ledger.
• SC5: the group-committed ledger is edited in place (group_commit::edit_value / state::save_state_shared) and no longer copied on every save.
• V-2: the pnpm-lock.yaml split is memoized (a ParseMemo keyed on the lock bytes), with its sections indexed. The index is built only once the same lock lines get a second package probe (cfeafb0). On a fresh run every package rewrites the lock, so each re-seeded lock is probed exactly once. Building the index for that single probe had pushed depscan vendored fresh from 13.36G to 15.82G instructions (+18%). That probe now goes through the old scans; the equivalence test already holds their answers equal to the index's. An idempotent re-run probes one unchanged lock once per package and still indexes it once. A new test checks that a single probe leaves the index unbuilt.
• V-7: byte-keyed memos for the cargo in-sync re-run (root manifest, packages, workspace members) and a registry-pin slot for each manifest the residue check reads.
• DC-6: the python site-packages probe runs once per environment (KeyedMemo, which stores only successful queries).

Every item is meant to preserve behavior. Three adversarial reviewers checked the WP: 5 findings fixed, 1 deferred and documented (512-slot memo FIFO eviction).

Before → after (previous PR head f9fc676 vs cfeafb0, release builds, replay proxy)

Polyglot monorepo (~158k files, 8 ecosystems):

step	lat	instructions	wall	peak RSS
hdry	0 ms	40.51G → 40.33G	3.80s → 4.00s	158 → 155 MiB
hwet	0 ms	40.67G → 41.00G	3.68s → 3.92s	166 → 168 MiB
vfresh	0 ms	119.25G → 106.91G (−10.3%)	9.77s → 8.82s	524 → 451 MiB
vrerun	0 ms	78.99G → 39.79G (−50%)	6.01s → 3.54s (−41%)	416 → 388 MiB
hwet	100 ms	40.95G → 40.53G	18.76s → 18.58s	171 → 168 MiB
vfresh	100 ms	119.61G → 109.38G (−8.6%)	120.65s → 120.05s	601 → 457 MiB

The 0 ms vfresh/vrerun rows were re-measured on cfeafb0. The other rows are from e369bf4 (cfeafb0 without the V-2 fix). The fix only touches the pnpm vendored path, so those rows are not expected to move, and the 100 ms vfresh row is, if anything, pessimistic.

depscan (2 interleaved reps each, 0 ms):

run	instructions	wall	peak RSS
hosted dry-run	12.44G / 10.45G → 10.51G / 10.48G	1.94s / 1.41s → 1.81s / 1.41s	116 / 117 → 117 / 115 MiB
vendored fresh	13.35G / 13.32G → 10.50G / 10.49G (−21%)	2.01s / 1.69s → 1.69s / 1.61s	97 / 99 → 107 / 104 MiB

The first hosted rep is cold for both binaries (12.4G then 10.4G). Warm, hosted is flat. Vendored fresh is now 21% cheaper, where the previous draft of this WP regressed it by 18%. It costs about +8 MiB peak RSS, because the memo holds the 2 MB lock's bytes and lines.

Byte-equality

Polyglot gate at 0 ms on vfresh/vrerun with cfeafb0, and on hdry/hwet with e369bf4. Canonical stdout, stderr, exit codes, request counts by kind and the full work-tree digest are identical between the two binaries. The digest covers 250-274k entries: every file hash with timestamps masked, plus symlinks and dirs. For depscan, the canonical stdout (hosted and vendored) is identical, and so are pnpm-lock.yaml, pnpm-workspace.yaml, package.json, the vendor ledger and every vendored artifact and marker (timestamps masked). Canonical stdout sorts arrays, because the order of the per-package vendored warnings follows fetch completion and already varies from run to run on f9fc676.

Tests

cargo clippy --workspace --all-targets -D warnings: clean. cargo test --workspace --no-fail-fast: 9230 passed, 0 failed, 136 ignored (262 test binaries).

🤖 Generated with Claude Code