feat: introduce SNYK_REQUEST_CONCURRENCY for dependency request parallelism

[bgardiner]

What does this PR do?

Adds a tunable concurrency knob for in-flight dependency-test / dependency-monitor HTTP requests, and bumps the default from 5 to 10.

• New helper getRequestConcurrency() in src/lib/snyk-test/common.ts — reads SNYK_REQUEST_CONCURRENCY, defaults to 10, clamps to [1, 50].
• Replaces the hard-coded MAX_CONCURRENCY = 5 constant at the existing pMap call site in sendAndParseResults (src/lib/snyk-test/run-test.ts).

A follow-up PR (#6757) adopts the same helper in src/lib/ecosystems/monitor.ts:monitorDependencies, which is currently fully sequential.

Why?

snyk container test produces one ScanResult per directory of dependencies in the image (lib/analyzer/applications/java.ts:groupJarFingerprintsByPath in snyk-docker-plugin). For Java-heavy images this can be hundreds of ScanResults, each becoming a separate POST /test-dependencies request. With the prior concurrency cap of 5, the request fan-out is the dominant wall-clock cost.

Benchmark — quay.io/wildfly/wildfly:34.0.1.Final-jdk21 (512 ScanResults)

hyperfine --warmup 1 --runs 3 against the same locally-built PR binary, varying only SNYK_REQUEST_CONCURRENCY to isolate the API concurrency change from any other build/runtime differences. The c=5 row reproduces the prior hard-coded value, so it's an apples-to-apples baseline.

Configuration	Mean wall-clock	vs baseline
baseline (c=5)	68.04 s ± 1.72 s	1.00×
PR default (c=10)	40.96 s ± 0.15 s	1.66× faster (−40%)
PR override (c=20)	25.13 s ± 0.48 s	2.71× faster (−63%)

Min/max within ±2% of mean across all configs — variance is tight. Standard deviation drops with higher concurrency (1.72s → 0.15s → 0.48s) because the wait-time component shrinks and the scan becomes more CPU-bound on the (much steadier) JAR-extraction work in snyk-docker-plugin.

For non-container test workloads the default bump is essentially a no-op:

• Single-project tests produce one payload.
• --all-projects rarely produces more than the prior 5-payload ceiling.

Where should the reviewer start?

• src/lib/snyk-test/common.ts — new helper.
• src/lib/snyk-test/run-test.ts — single call-site swap.
• test/jest/unit/lib/snyk-test/common.spec.ts — 9 new unit tests for the helper covering default, override, clamping, and invalid-input cases.

How should this be manually tested?

1. Run targeted unit tests:

   npx jest --selectProjects coreCli --testPathPattern 'test/jest/unit/lib/snyk-test/common.spec'

2. Optionally measure on a representative many-ScanResult image (Wildfly works well):

   hyperfine --warmup 1 --runs 3 \
     'SNYK_REQUEST_CONCURRENCY=5 node bin/snyk container test quay.io/wildfly/wildfly:34.0.1.Final-jdk21' \
     'node bin/snyk container test quay.io/wildfly/wildfly:34.0.1.Final-jdk21' \
     'SNYK_REQUEST_CONCURRENCY=20 node bin/snyk container test quay.io/wildfly/wildfly:34.0.1.Final-jdk21'

Risk assessment

Low. The change is scoped to a single constant + a small env-var helper. Default behavior change (5 → 10) only affects test invocations that produce more than 5 payloads, which today means container tests and large --all-projects runs. The override is bounded to [1, 50] to prevent footguns.

Background

Supersedes #6747 (which targeted the wrong code path — src/lib/ecosystems/test.ts:testDependencies is unreachable from snyk container test; getEcosystemForTest returns null for docker, so container test goes through runTest/pMap instead).

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

	Warnings
⚠️	"feat: introduce SNYK_REQUEST_CONCURRENCY for dependency request parallelism" is too long. Keep the first line of your commit message under 72 characters.

Generated by 🚫 dangerJS against 6764f65

[bgardiner]

Benchmark — quay.io/wildfly/wildfly:34.0.1.Final-jdk21 (512 ScanResults)

hyperfine --warmup 1 --runs 3 against the same locally-built PR A binary, varying only SNYK_REQUEST_CONCURRENCY to isolate the API concurrency change from any other build/runtime differences. The c=5 row reproduces the prior hard-coded value, so it's an apples-to-apples baseline.

Configuration	Mean wall-clock	vs baseline
baseline (c=5)	68.04 s ± 1.72 s	1.00×
PR A default (c=10)	40.96 s ± 0.15 s	1.66× faster (−40%)
PR A override (c=20)	25.13 s ± 0.48 s	2.71× faster (−63%)

Each config: 3 runs after 1 warmup; image pre-pulled. Min/max within ±2% of mean across all configs — variance is tight.

Standard deviation drops with higher concurrency (1.72s → 0.15s → 0.48s) because the wait-time component shrinks and the scan becomes more CPU-bound on the (much steadier) JAR-extraction work in snyk-docker-plugin.

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Sub-optimal fallback logic 🟡 [minor] The getRequestConcurrency function returns DEFAULT_REQUEST_CONCURRENCY (10) when the parsed value is less than MIN_REQUEST_CONCURRENCY (1). If a user explicitly sets SNYK_REQUEST_CONCURRENCY=0 to attempt to minimize load or debug sequential execution, the code will silently revert to 10. It would be more intuitive to return MIN_REQUEST_CONCURRENCY in this specific case. if (!Number.isFinite(parsed) || parsed < MIN_REQUEST_CONCURRENCY) { return DEFAULT_REQUEST_CONCURRENCY; }

📚 Repository Context Analyzed This review considered 15 relevant code sections from 5 files (average relevance: 0.78) src/lib/snyk-test/run-test.ts (9 segments, lines 301-400) help/cli-commands/test.md (lines 1-100) src/cli/main.ts (lines 1-100) package.json (lines 1-100) src/lib/snyk-test/common.ts (3 segments, lines 101-200)

[bdemeo12]

Same questions as this PR: #6757

But LGTM

[PeterSchafer]

Suggestion: There is already a similar configuration value in the Golang CLI. While this is currently not publicly documented, I think we should inject it in the Legacy CLI and have the Golang configuration a single source of truth for this. We can also expose the config value but would probably want to frame it around SNYK_MAX_CONCURRENCY rather then focussed on requests.

[PeterSchafer]

Thinking: Generally changing a default without visibility in the behaviour, we currently don't have any metrics on CPU consumption, makes me wonder if we should be more careful. The impact is quite huge as it affects all SCA and Container scans.