feat: parallelize container monitor dependency requests

[bgardiner]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages
  are release-note ready, emphasizing
  what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be announced in the next stable release notes

What does this PR do?

This PR improves performance for ecosystem/container monitoring by changing the /monitor-dependencies request flow from fully sequential to hybrid execution:

• For each path, it always executes the first ScanResult request first (base OS project ordering retained)
• It then executes the remaining ScanResult requests in parallel
• It preserves output ordering by collecting parallel responses and appending them in scan order
• It preserves existing error semantics:
  • 401 still throws AuthFailedError
  • other 4xx errors still throw MonitorError
  • non-4xx failures are collected as monitor errors and execution continues

Where should the reviewer start?

• src/lib/ecosystems/monitor.ts
• test/jest/unit/ecosystems-monitor-docker.spec.ts

How should this be manually tested?

1. Run monitor unit tests:
   • npm run test:unit -- --runTestsByPath test/jest/unit/ecosystems-monitor-docker.spec.ts
2. Optionally run a representative multi-project container monitor command and compare runtime:
   • snyk container monitor <image>

What's the product update that needs to be communicated to CLI users?

Container monitor execution is now faster for images that produce multiple scan results. The CLI now keeps base OS processing first and parallelizes the remaining dependency API requests.

Risk assessment (Low | Medium | High)?

Low. This is a scoped orchestration change with focused tests that verify ordering and existing error semantics.

Any background context you want to provide?

Large images that produce many scan results can experience long monitor durations due to sequential API calls; this change addresses that bottleneck.

What are the relevant tickets?

N/A

  

[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.