[codex] Cap concurrent plugin probes per batch

[zergzorg]

Summary

• cap each probe batch to at most 4 concurrent plugin probe workers
• keep queued plugins inside the same batch instead of spawning every enabled plugin at once
• preserve the existing probe:result and probe:batch-complete event flow
• add a small unit test for the worker-count cap

Why

This is another small slice of #487. A batch can include many enabled providers, and the previous implementation spawned one blocking task per plugin immediately. That is simple, but it can create avoidable CPU/thread/process pressure when several plugins do filesystem, network, SQLite, keychain, or helper-process work at the same time.

The new queue keeps provider results asynchronous but limits batch fan-out, so background refreshes have a bounded resource profile.

Notes

The cap is intentionally conservative and local to backend batch execution. It does not change polling intervals, provider enablement, manual refresh behavior, or the frontend event contract.

Validation

• bun run bundle:plugins
• cargo test probe_worker_count_is_bounded
• bun run build
• node ./node_modules/vitest/vitest.mjs run

I also ran full cargo test; Rust compilation and 96 tests passed, but an existing ccusage process-timeout test fails locally while trying to read descendant.pid before it exists. I did not change that unrelated test in this PR.

Part of #487.

---

Summary by cubic

Cap concurrent plugin probes per batch to 4 to bound CPU and thread usage. Results stay async and probe:result/probe:batch-complete events are unchanged.

• Refactors
  • Use a small worker pool per batch and queue remaining plugins inside the batch.
  • Cache successful outputs as before; no changes to polling intervals, provider enablement, manual refresh, or the frontend contract.
  • Add probe_worker_count_is_bounded test to verify the cap.

^{Written for commit 7d3442f. Summary will update on new commits. Review in cubic}

[cubic-dev-ai]

No issues found across 1 file

_{Re-trigger cubic}

[zergzorg]

Stack note for maintainers/agents:

Recommended #487 merge order:

1. [codex] Skip auto-update probes already in flight #498 first: skip duplicate auto-update probes for providers already in flight.
2. [codex] Cap concurrent plugin probes per batch #499 second: cap backend batch fan-out to 4 probe workers.
3. [codex] Add per-probe runtime deadline #500 third: add a per-provider runtime deadline.

This PR is based on main and has no hard code dependency on #498 or #500. It is recommended after #498 conceptually: once duplicate provider work is avoided, this caps how many different providers a batch can run at once.

#490 is separate from this stack and can merge anytime.

[validatedev]

@codex review

[Copilot]

Pull request overview

Caps per-batch plugin probe fan-out by introducing a small worker pool (max 4) and an in-batch queue, reducing CPU/thread/process pressure during background refreshes while preserving the existing probe:result and probe:batch-complete event contract.

Changes:

• Add MAX_CONCURRENT_PROBES and probe_worker_count() to bound probe concurrency per batch.
• Refactor start_probe_batch to use a shared VecDeque work queue processed by up to 4 spawn_blocking workers.
• Add a unit test (probe_worker_count_is_bounded) validating the worker cap behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Bravo.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".