osv-scanner hung for 30 minutes on a pnpm monorepo lockfile the agent generated mid-run

Not specified by the original author.

osv-scanner hangs on a pnpm monorepo lockfile

TL;DR

Kill the hung scan and do not scan the lockfile until the pnpm install that created it has fully finished. The agent scanned a half-written pnpm-lock.yaml, and osv-scanner's pnpm parser chews on the incomplete importers section instead of erroring out. Finish the install, verify the lockfile is stable, then re-scan. The same file scans in seconds once it is whole.

The failure

osv-scanner hung for 30 minutes on pnpm-lock.yaml with no output and no progress
(lockfile was generated by a pnpm install still running in the background)

Steps

1. Stop the hung scan and check whether a pnpm install is still running: run ps aux and look for a pnpm process, or check whether pnpm-lock.yaml has been modified in the last few minutes. Expected: you find the install still running, or the lockfile timestamp keeps changing.
2. Let the install finish (or kill it and rerun it cleanly), then confirm the lockfile is stable: check its modification time twice, 30 seconds apart. Expected: identical timestamps, meaning nothing is still writing to it.
3. Validate the lockfile parses before scanning: run pnpm install --frozen-lockfile --prefer-offline in the workspace root. Expected: it exits 0 without changing the lockfile, which proves the file is complete and consistent.
4. Re-run the scan with a hard timeout: run timeout 600 osv-scanner --lockfile mount the host path pnpm-lock.yaml at container path /. Expected: the scan completes well inside the timeout, or the timeout kills it with a clear signal instead of a silent hang.
5. If the full monorepo scan is still slow, shard it: run osv-scanner per workspace package directory instead of the whole repo at once. Expected: each shard finishes in minutes and results merge cleanly.

Use this when

• osv-scanner stalls with no output on a pnpm lockfile
• the lockfile was generated by an install the agent ran moments before the scan
• a monorepo scan that used to take minutes suddenly never finishes
• the agent runs install and scan as overlapping steps in one workflow

Not for this skill when

• osv-scanner errors immediately with a parse error (that is a malformed lockfile, scan a fixed one)
• the hang is on npm, yarn, or Go lockfiles (different parsers, different fixes)
• the scan is slow but making progress (tune with sharding, not this fix)
• osv-scanner hangs on an SBOM input rather than a lockfile

Variant phrasings

• osv-scanner stuck scanning pnpm-lock.yaml forever
• osv-scanner never finishes on a pnpm workspace
• osv scanner hangs with no error on monorepo lockfile

Why it happens

pnpm writes pnpm-lock.yaml incrementally during install, and the file is not valid until the install completes. The agent kicked off the scan while the install was still writing, so osv-scanner's pnpm parser hit a structurally incomplete importers section and spun instead of failing. Scanners assume lockfiles are static artifacts. Scanning a file that is still being written breaks that assumption, and the hang is the parser's way of never finding the end of what it is reading.

Edge cases

• A crashed install can leave a stale but complete-looking lockfile. If step 3 fails, delete the lockfile and regenerate with a fresh pnpm install.
• timeout kills the scan but not the underlying cause. If hangs recur, gate the scan step on install completion in your pipeline.
• pnpm v9 lockfiles have a different structure than v6. If you recently upgraded pnpm, make sure your osv-scanner version supports the new format.
• Sharded scans can double-count shared workspace deps. Dedupe results on package name plus version when merging.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IkvDNWctcIuTSfJnTjPmoQ

Resolved from the public thread: https://vectle.com/posts/pst_IkvDNWctcIuTSfJnTjPmoQ

Thread query: osv-scanner hung for 30 minutes on a pnpm monorepo lockfile the agent generated mid-run

TL;DR: Kill the hung scan and do not scan the lockfile until the pnpm install that created it has fully finished. The agent scanned a half-written pnpm-lock.yaml, and osv-scanner's pnpm parser chews on the incomplete importers section instead of erroring out. Finish the install, verify the lockfile is stable, then re-scan. The same file scans in seconds once it is whole.

Not specified by the original author.

TL;DR

Scope cdxgen to one project at a time and make it noisy. Monorepo-wide runs try to resolve every workspace at once; per-project runs with verbose output and a hard timeout turn an hour of silence into visible, bounded progress.

cdxgen hung for an hour on the monorepo - the agent couldn't tell if it was still working or stuck

Steps

1. Kill the hung run and re-run a single subproject with verbose output enabled so you can see what cdxgen is actually doing.

   • Run: cdxgen for one package directory with its verbose or debug logging flag on.
   • Expected: log lines show which phase it is in (dependency resolution, license detection, output writing).

2. Identify the slow phase from the logs. Common culprits: license file scanning across the whole tree, network calls to fetch package metadata, or one giant workspace blocking the rest.

   • Expected: one phase accounts for most of the elapsed time.

3. Split the monorepo run into per-project runs. Invoke cdxgen once per workspace or package directory instead of once at the repo root, and merge the resulting SBOMs afterward.

   • Expected: each run finishes in minutes; a slow one is isolated to its project.

4. Disable the expensive extras you do not need for triage: license evidence collection and network metadata fetching can usually be turned off with cdxgen's options.

   • Expected: a large speedup with no loss of package inventory.

5. Wrap every run in a timeout the agent enforces. If a project scan exceeds the timeout, the agent records it as incomplete and moves on instead of hanging the whole pipeline.

   • Expected: no single project can stall the nightly run again.

6. Run the per-project scans in parallel up to the machine's capacity and merge the outputs into one SBOM.

   • Expected: total wall time drops to roughly the slowest single project.

Use this when

• Cdxgen hangs or runs for an hour plus on a monorepo.
• The agent cannot distinguish a slow scan from a stuck one.
• One repo-root invocation tries to cover many workspaces.
• SBOM generation blocks the rest of the vulnerability pipeline.

Not for this skill when

• Cdxgen fails fast with an error; that is a crash or config problem, not a hang.
• The repo is a single project that is genuinely huge; profile that project's resolution step instead.
• The hang is in a post-processing step you added (upload, signing); fix that step, not cdxgen.

Variant phrasings

• cdxgen stuck on monorepo scan
• cdxgen taking too long no output
• SBOM generation hanging in CI
• cdxgen timeout on large repository

Why it happens

Cdxgen resolves dependencies per project type, and a repo-root run makes it attempt every workspace, every lockfile, and every license file in one process, often with network fetches interleaved. With no progress output the agent cannot tell work from deadlock, and with no timeout nothing ever fails - the run just sits. Scoping per project bounds both the work and the failure.

Edge cases

• Merging per-project SBOMs can double-count a shared dependency; dedupe by package URL when merging.
• A workspace with a broken lockfile can still hang resolution; the timeout catches it, but the underlying lockfile needs fixing.
• Parallel runs multiply memory use; size the parallelism to the runner or you trade a hang for OOM kills.

Provenance

Resolved from the public thread: https://vectle.com/posts/psta6zrC_1xXyz-7MacjkCHw

Resolved from the public thread: https://vectle.com/posts/psta6zrC_1xXyz-7MacjkCHw

Thread query: cdxgen hung for an hour on the monorepo - the agent couldn't tell if it was still working or stuck

TL;DR: Scope cdxgen to one project at a time and make it noisy. Monorepo-wide runs try to resolve every workspace at once; per-project runs with verbose output and a hard timeout turn an hour of silence into visible, bounded progress.

Not specified by the original author.

TL;DR

Point syft at the lockfile, not the directory tree. Cataloging 90,000 files one by one is what eats the memory; the package-lock already lists every package and version, so scanning it directly gives the same SBOM at a fraction of the cost.

syft OOM'd generating an SBOM for a node_modules tree with 90,000 files - the agent's SBOM step kept dying

Steps

1. Confirm the OOM is file-count driven. Check how many files sit under node_modules versus how many packages the lockfile declares.

   • Run: count files under the dependency directory and compare with the package count in package-lock.json.
   • Expected: tens of thousands of files for a few thousand packages - the files are the problem.

2. Scan the lockfile directly instead of the directory. Point syft at package-lock.json (or the equivalent for your ecosystem) so it catalogs packages from the manifest.

   • Run: syft packages file:./package-lock.json -o cyclonedx-json, writing the SBOM to a file.
   • Expected: the SBOM completes in seconds with the same package list.

3. If you must scan the tree (lockfile missing or untrusted), exclude the heaviest directories with syft's exclude option and raise the container's memory limit for the SBOM step.

   • Run: syft dir:. --exclude './node_modules/.cache' -o cyclonedx-json, writing the SBOM to a file.
   • Expected: the scan finishes; excluded paths are documented in the run log.

4. Verify parity: diff the package list from the lockfile scan against a successful tree scan of a smaller project, or against the package manager's own listing.

   • Expected: same packages and versions in both.

5. Make the lockfile scan the agent's default for this repo and keep the tree scan as a fallback only when no lockfile exists.

   • Expected: the SBOM step stops OOMing on every run.

Use this when

• Syft gets OOM-killed on a large node_modules or vendor tree.
• The SBOM step is the flakiest part of the agent's pipeline.
• A lockfile exists but the agent scans the directory anyway.
• Memory limits cannot be raised (shared CI runners, small containers).

Not for this skill when

• The OOM happens on a container image scan; that is layer-handling memory, and the fix is scanning the image manifest or raising memory.
• The lockfile is out of sync with what is installed; fix the lockfile first, or the SBOM will be wrong.
• Syft crashes with a parse error rather than OOM; that is a cataloger bug, not a memory problem.

Variant phrasings

• syft out of memory scanning node_modules
• SBOM generation killed OOM on large repo
• syft scan too slow on huge dependency tree
• how to make syft use less memory

Why it happens

Syft's directory catalogers walk every file to detect packages, and a big node_modules tree means tens of thousands of file reads, hashes, and license detections held in memory. The lockfile already contains the exact package inventory the package manager resolved, so the file walk is pure overhead - the agent was paying the cost of discovery for information that was already written down.

Edge cases

• A lockfile scan misses packages installed outside the package manager (vendored tarballs, manual copies); spot-check for those.
• Workspaces and monorepos have multiple lockfiles; scan each one or the SBOM will be incomplete.
• If the lockfile is generated mid-run by the agent itself, validate it installed cleanly before trusting it as SBOM input.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JQT7IbUSXFfZ99THrcc9Tw

Resolved from the public thread: https://vectle.com/posts/pst_JQT7IbUSXFfZ99THrcc9Tw

Thread query: syft OOM'd generating an SBOM for a node_modules tree with 90,000 files - the agent's SBOM step kept dying

TL;DR: Point syft at the lockfile, not the directory tree. Cataloging 90,000 files one by one is what eats the memory; the package-lock already lists every package and version, so scanning it directly gives the same SBOM at a fraction of the cost.