[Mikola Lysenko (mikolalysenko)]

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

Fixes #614

Summary

When the public proxy rejects a batch-search chunk (a validation 400, which one exotic PURL is enough to cause) or predates POST /patch/batch, the client falls back to one GET per package. That fallback kept up to 10 requests in flight because of a private constant. So it ignored the proxy cap of 4 and SOCKET_API_CONCURRENCY (=1 still sent 10 at once), and it stayed concurrent under a tight RLIMIT_NOFILE.

Root cause

api/client.rs set the size of the proxy batch path's slot pool and fallback groups from PROXY_BATCH_PATH_CONCURRENCY = 10. Every other patch-API window gets its limit from utils::concurrent::api_concurrency.

Changes

• A proxy client sizes proxy_batch_slots from api_concurrency(true) when it is built: 4 by default, lower under SOCKET_API_CONCURRENCY, and 1 under a tight fd limit. An org client never uses these slots and doesn't read the env for them, so it adds no duplicate --debug "ignoring SOCKET_API_CONCURRENCY" line.
• PROXY_BATCH_PATH_CONCURRENCY is deleted. No patch-API pacing constant is left outside utils::concurrent.
• The fallback no longer runs its GETs in fixed groups. Every GET waits on the shared slot pool, so one slow or throttled GET holds one slot instead of stalling a whole group. The first throttle error is still reported in input order, as before.
• The doc comment on search_patches_batch no longer says "concurrency 10".

Behavior change (intended, per the issue's acceptance criteria): the default fallback fan-out on the public proxy drops from 10 to 4. On the proxy the override can only lower the cap, by design (utils/concurrent.rs).

The issue's second point (registry_concurrency() had no caller) is already resolved on main: it is now called from patch/redirect/upstream/client.rs and upstream/npm.rs.

Tests (red → green)

Issue criterion	Test	Without fix	With fix
peak equals api_concurrency(true) (4), not 10	proxy_batch_path_cap_tests::concurrent_batches_share_the_legacy_fallback_cap	FAILED: "10 by-package GETs in flight at once; the cap is 4"	ok
SOCKET_API_CONCURRENCY=1 gives a peak of 1	proxy_batch_path_cap_tests::the_legacy_fallback_honors_the_concurrency_override	FAILED: left 10, right 1	ok

The tests set SOCKET_API_CONCURRENCY only while the client is built (it is read there) and restore it right away, so the variable is never left set while other tests run.

Local checks

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core --all-features --lib: 6924 passed, 4 failed. The 4 failures (copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_…, pypi_requirements::wire_failure_rolls_back_…) depend on read-only directories blocking writes. They fail only because this sandbox runs as root (uid 0), are unrelated to this diff, and CI runs as non-root.
• cargo test -p socket-patch-cli --all-features --lib --bins: 936 passed
• cargo test -p socket-patch-cli --all-features --test scan --test cli --test scan_api_retry_e2e: 247 + 113 + 5 passed
• A full cargo test --workspace ran out of disk in the sandbox while linking every e2e binary, so CI is the full-suite gate. No wrapper (npm/, pypi/, gem/) is affected: this is client-internal pacing.

Code review (/code-review high)

Fixed: chunk stalls (groups → shared slot pool), the stale "concurrency 10" doc, a slow 12 s serial test (now 6 GETs), the env var left set during the test, the env read and debug line on org clients, and a duplicate test EnvGuard.
Not fixed:

• "Default drops 10 → 4": this is the change The public-proxy per-package fallback runs 10 requests in flight, ignoring SOCKET_API_CONCURRENCY and the proxy cap of 4 #614 asks for.
• "Spawned fallback tasks don't inherit the hold_back_debug task-local": this predates the PR (the old code spawned the same way). It is out of scope and worth a separate issue.

https://claude.ai/code/session_011f9aeT8JHNQ414VVv6qyZm

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[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 3317a95. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review at 3317a9548e1b63a87d55e0df4ada67501cf45bad.

• CI: 82/82 checks on this head are success or skipped; ci-ok passed. Mergeable, no conflicts.
• Bugbot: reviewed 3317a95, no findings; no open review threads.
• Reviewer focus: api/client.rs. The proxy batch fallback now takes its GET concurrency from api_concurrency(true) (4 by default) instead of a hard-coded 10, and uses a shared slot pool instead of fixed groups. This is an intended behavior change: the default fallback fan-out drops from 10 to 4.
• The Slack announcement could not be sent this run because the send tool is not available. The next run will retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does. Fixes #614. When the public proxy rejects a batch chunk or lacks POST /patch/batch, the client falls back to one GET per package. That fallback kept up to 10 requests in flight because of a private constant, so it ignored the proxy cap of 4 and SOCKET_API_CONCURRENCY (=1 still sent 10). The slot pool is now sized from api_concurrency(true), and every fallback GET waits on that shared pool instead of running in fixed groups of 10.

Risk: low-medium. One file. Intended behavior change: the default fallback (and the batch POSTs that share the pool) drops from 10 to 4 in flight on the proxy, which can slow scans that hit the fallback.

Look here

• client.rs:458: pool size from api_concurrency(true) (proxy only)
• client.rs:1013: fallback now spawns one task per PURL, all gated by the pool; first throttle error still reported in input order
• client.rs:930: the POST's slot is released before the fallback runs, so a cap of 1 can't deadlock
• client.rs:6268: tests set the env only while the client is built, and are #[serial] with the other env tests

Verified. Read the full diff and the POST path. Ran cargo test -p socket-patch-core --all-features --lib proxy_batch_path_cap_tests: 2 passed (both fail on main per the PR's red→green table). PR CI ci-ok and clippy green on this head; Bugbot no findings; no review threads.

Changes I made. None.

Open questions. None blocking. Spawned fallback tasks don't inherit the hold_back_debug task-local; that predates this PR.

Auto-merge is armed, so approving sends it straight to the merge queue.

---

Generated by Claude Code