GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Fixes #760
Fixes #762

Summary

Hosted Poetry and PDM scans now rewrite poetry.lock / pdm.lock with one parse and one render per lock, not one of each per patched package. On the bench fixture (400 packages, 12 patched), the hosted scan's median wall time drops by about half:

(socket-patch-bench run -f '^<pm>/hosted', perf profile, both binaries alternated on the same sandbox runner.)

Root cause

Both rewriters go through the shared fragment-splice engine (utils/lock_fragments.rs::finish). For each patched dep, it mutated the parsed document, rendered the whole lock (DocumentMut::to_string), and parsed the rendering again to take the package's new fragments. LockParse only saved the input parse, so every dep still paid one full render and one full parse: O(patches × lock size). Callgrind put 77% of the hosted scan in this loop for both formats.

Fix

• lock_fragments::rewrite_batch (shared by both formats) handles every dep in one pass. It plans each dep against the document as the earlier deps left it, so refusal and not-found verdicts match the step-by-step ones. It then applies all mutations, renders and re-parses once, and splices each dep's changed bytes into the original text. The splice must reproduce the rendering byte for byte.
• The batch steps aside, and the old step-by-step path runs unchanged, when it can't vouch for an identical result: a lock with mixed line endings (the majority terminator that spells each spliced fragment can shift as deps land), a package rewritten twice in one run, an ambiguous fragment, or a failed check.
• poetry_lock / pdm_lock split their rewrite into checks, plan and mutate steps, and add rewrite_*_lock_all (batch or steps). They return a LockStep per dep: Rewritten(edits), Unchanged, NotFound or Refused.
• The hosted callers (patch/redirect/poetry.rs, patch/redirect/pdm.rs) consume those steps. Warnings, uuid sets and FileEdits come out in the same order as before. Vendored callers (one dep at a time) are unchanged.
• No wrapper changes: npm/, pypi/ and gem/ only dispatch to the binary.

Out of scope: both issues also note a secondary cost, vex::discover::pypi_locks::extract re-parsing the lock for VEX (~10%). It's untouched here and can be a follow-up if it still shows up in the bench.

Tests

Equivalence:

• utils::poetry_lock::batch_equivalence_tests::batch_matches_the_step_by_step_rewrite and utils::pdm_lock::batch_equivalence_tests::…: across every lock generation, LF / CRLF / mixed, with adjacent and sparse packages, reversed order, interleaved refusals and not-found deps, a package rewritten twice, and a re-run over the output, the batch's text and every dep's step equal the step-by-step result. The tests also assert the batch actually answers in every clean case and hands back in the mixed / rewritten-twice cases.
• The existing goldens (poetry_rewrite, pdm_plan, pdm_rewrite_shared_parse, pdm_lock_reused_parse, …) pass unchanged, so there are no output changes.

Local runs (on 6e45592):

• cargo clippy --workspace --all-features -- -D warnings: clean. Formatting follows the surrounding code. main itself isn't rustfmt-clean and CI doesn't check formatting, so I didn't run cargo fmt --all. 29735ea had run it and swept 117 unrelated files; 6e45592 restores them to main.
• cargo test -p socket-patch-core --all-features --lib: 5250 passed. The 4 failures (copy_tree, vlt_heal, pypi_poetry, pypi_requirements write-failure tests) are chmod-based. They can't fail when the sandbox runs as root, and they fail the same way on main. All 35 core integration targets pass.
• CLI: --lib (847), in_process_redirect_poetry, in_process_redirect_pdm, hosted_memory_engine, hosted_memory_parity, mode_migration_pypi, covgap_commands_vex, e2e_vex_vendor, in_process_vendor, in_process_python_envs: all pass.

CI on 6e45592: all green. All 12 workflows pass (CI, Poetry, PDM, vlt, Gradle, Go, Bun, Composer, npm, pnpm, Benchmarks, Audit GHA), including every e2e_vex_build Poetry leg (1.0.10–2.4.3) and PDM leg (1.4.5–2.29.2). Jobs that the runner queue had cancelled before any step ran were re-run once. Bugbot found no issues; no open review threads.

Also in this PR

c25dd8e cherry-picks #878 (Route Gradle digests through utils::digest). main @ 9c43dfc fails utils::digest::tests::production_digests_go_through_the_helpers on every PR. The cherry-pick becomes a no-op once #878 merges.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HBf8J4E4vApc1bRJfAUDu8

Generated by Claude Code