GeezerVison

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

Fixes #1471

Summary

A hosted scan of a Hatch project now wires every patched PyPI dependency over one parse and one render of pyproject.toml / hatch.toml, instead of re-parsing, re-checking every declared requirement and re-rendering both files once per dependency. Scan time no longer grows with the square of the number of patched pins.

Root cause

patch::redirect::rewrite_hatch called utils::hatch::rewrite once per patched dep. Each call parsed both Hatch documents, cloned the Hatch tables, ran canonicalize_pypi_name on every declared requirement and rendered both documents again. The redirect lane then stored a whole-file snapshot of each changed document per dep. With N patched deps pinned in the Hatch environments that is O(N²) work, and utils::hatch::plan was 40% of Ir in the bench profile. The cost grew as more pins and Hatch features landed (#700, #1336), which explains the slow drift the bench saw.

Fix

• New utils::hatch::rewrite_all(files, deps) -> HatchBatch. It parses once, walks every declaration once per round, looks each requirement up by canonical name in a map, and renders once.
• Each dep gets exactly the outcome a lone rewrite would give it after the deps before it:
  • a check pass records refusals without changing anything;
  • the apply pass rewrites only the deps that passed, so a dep refused midway keeps all of its declarations;
  • a structural refusal (dynamic deps, Hatch sources/overrides/custom envs, a non-array) fails every dep not already refused, in the same walk order as plan;
  • repeats of one canonical name run one per round in input order (e.g. a superseding url);
  • the direct-reference permission and the {root:uri} pip-installer and dependency-group refusals keep their per-dep semantics.
• plan (vendored lane) runs the same engine with one dep, so both lanes share one walk.
• Redirect edits now record the requirement strings each dep rewrote (redirect_hatch_requirement) and the permission grant (redirect_hatch_permission), not a full copy of the file per dep. Hosted edits aren't part of --json output, and v5 keeps no hosted ledger that replays them (patch/redirect/state.rs: "Its recorded edits are never replayed"). The vendored ledger's hatch_document kind is unchanged.

Test evidence

New tests in crates/socket-patch-core/src/utils/hatch.rs:

• batch_rewrite_matches_sequential_rewrites: batch vs one-at-a-time rewrite across successes, inexact pins, missing declarations, extras/markers, differently spelled names, and a repeated name with a superseding hosted url.
• batch_rewrite_follows_merges_and_refusal_order: hatch.toml envs shadowing pyproject's, a refusal in a later table leaving earlier declarations untouched, structural refusals, a parse error. Exact rendered output and edit lists are pinned, so the test doesn't depend only on the shared walk.
• batch_rewrite_records_a_permission_only_change: a re-run that only restores a removed allow-direct-references, an already-granted permission, and a user false.
• batch_rewrite_keeps_root_placeholder_refusals: vendored {root:uri} refusals beside hosted deps.

This is a performance fix, so there is no red→green behavioural test. The evidence is the bench (perf profile, socket-patch-bench compare, 4 vCPU sandbox):

Against the issue's base, both scenarios are back within the 10% gate.

Local runs on b6cef30:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core --all-features --lib: 6411 passed, 4 failed. The 4 also fail on main in this sandbox: they make a directory read-only and expect a write to fail, and the container runs as root.
• cargo test --workspace --all-features --no-fail-fast: only those root-only write-failure tests failed, plus e2e_bun_lockb::binary_shared_bundled_record_hosted_pin_is_managed, which needs patches-api.socket.dev and the sandbox proxy blocks it. No Hatch, PyPI or redirect test failed.
• Hatch e2e, SOCKET_PATCH_HATCH_E2E_REQUIRED=1 SOCKET_PATCH_HATCH_E2E_VERSION=1.18.1 cargo test -p socket-patch-cli --all-features --test e2e_vex_build -- hatch:: --ignored: 6 passed.

No wrapper changes: npm/, pypi/ and gem/ only dispatch to the binary.

/code-review high findings not changed

• Apply-pass error leaves documents partly rewritten: can't happen. The check and apply passes walk the same structure with the same function. Between them only string values change, and the check pass skips the table write-back. The permission grant is tried on a copy first.
• Check pass clones tool.hatch / hatch.toml; permission probe clones the document: one clone per round, not per dep, so linear. Not worth the extra code.
• rewrite_array returns a Vec most callers drop: an empty Vec doesn't allocate, and only group matches push into it.
• Step/dep pairing uses a cursor: deps is built from the same url.is_some() filter a few lines above the loop that consumes the steps, and the expect guards the invariant.
• Edit kind changed: see Fix. No consumer reads hosted edits by kind, and they aren't in --json output.

Follow-ups

The remaining hatch/hosted hot spots from the issue (PurlKey::new / canonical_base_purl, list_dist_info_packages_sync name canonicalization) are shared with every PyPI lane and not part of this regression.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Tr9PtQHqFihp4KcdJ1pXCK

Generated by Claude Code