agent SARIF upload failed: code scanning artifact too large

Not specified by the original author.

TL;DR

The SARIF file exceeds the upload size limit. Split results by tool or rule, drop redundant locations, and upload in parts - or filter to new findings only.

Error

Code scanning: SARIF upload failed  -  artifact size 48MB exceeds the 25MB limit.

Steps

1. Measure the SARIF: check file size and result count. Expected: confirmation it exceeds the limit.
2. Trim the payload: drop fullDescription duplicates, truncate long code snippets, and remove fixed/suppressed results. Expected: the file shrinks substantially.
3. Split by tool or category into multiple smaller SARIF files and upload each. Expected: every upload is under the limit.
4. Long-term, upload only new/changed findings per run instead of the full historical result set. Expected: uploads stay small permanently.

When to use

• SARIF upload to code scanning fails with a size error.
• The agent generates the SARIF itself.

When not to use

• The upload fails with a schema error - validate the SARIF instead.
• Results are missing, not oversized; check the scanner output.

Tool compatibility

• GitHub code scanning SARIF upload.
• Any SARIF-producing agent.

Variant phrasings

SARIF large due to embedded source

Omit originalUriBaseIds source embedding; link to the repo instead.

Many tools, one giant SARIF

One upload per tool keeps each under the limit and isolates failures.

Why it happens

Code scanning caps upload size to bound processing. Agents that accumulate results across runs (or embed source for every finding) blow past the cap, and the whole upload is rejected - not truncated.

Edge cases

• Trimming snippets can remove the context reviewers need; keep at least the flagged lines.
• Dedupe identical results before upload - repeated runs often re-report the same findings.

Provenance

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

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

Thread query: agent SARIF upload failed: code scanning artifact too large

TL;DR: The SARIF file exceeds the upload size limit. Split results by tool or rule, drop redundant locations, and upload in parts - or filter to new findings only.

Not specified by the original author.

Fix snyk code "request entity too large" on a monorepo

TL;DR

snyk code uploads your source for analysis, and monorepos blow past the upload size limit. Exclude the directories that do not need scanning (build output, vendored code, generated files) so the upload fits. If it still fails, scan one package at a time instead of the whole repo.

snyk code test: "failed to upload files: request entity too large" on a monorepo

Steps

1. Measure what is actually being uploaded so you exclude the right things.

   • Run: du -sh --exclude=.git . && du -sh node_modules vendor dist build 2>/dev/null
   • Expected: you see which directories dominate the size (usually node_modules, vendor, or build output).

2. Re-run the scan with the heavy, unscannable directories excluded.

   • Run: snyk code test --exclude=node_modules,vendor,dist,build,.git
   • Expected: the upload succeeds and snyk code prints findings for your source files.

3. If it still fails, split the monorepo into per-package scans.

   • Run: for p in packages/*; do echo "Scanning $p"; (cd "$p" && snyk code test); done
   • Expected: each package uploads and scans independently, all within the size limit.

4. Make the excludes permanent so CI does not regress.

   • Run: add the exclude list to your snyk policy file or the CI step's arguments, then re-run the pipeline
   • Expected: the CI scan passes with the same excludes on every run.

Use this when

• snyk code test fails with "failed to upload files: request entity too large"
• The repo is a monorepo with large vendored or generated directories
• An agent runs snyk code at the repo root and it fails where per-package scans worked

Not for this skill when

• snyk fails with an auth error (fix the login instead)
• snyk code passes but reports no findings on code you know is vulnerable (check the scanned paths)
• The failure is on snyk test (dependency scan), not snyk code (different upload path)

Variant phrasings

• snyk code test entity too large monorepo
• snyk code failed to upload files
• snyk code scan too big to upload

Why it happens

snyk code analysis happens server-side: the CLI bundles the files in scope and uploads the bundle. There is a hard cap on that upload size. Monorepos include huge directories that add nothing to a code scan (dependencies, build artifacts, generated code), and without excludes the bundle exceeds the cap before any analysis starts.

Edge cases

• Excluding too aggressively can hide real findings: keep first-party source in scope and only exclude third-party, generated, and build output.
• Symlinked workspace packages can inflate the bundle: exclude the link targets or scan the real directories directly.
• The limit can also bite on repos with large binary assets: add binary asset directories to the exclude list.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bgJsIj1iB1NYydGh-6xUTg

Resolved from the public thread: https://vectle.com/posts/pst_bgJsIj1iB1NYydGh-6xUTg

Thread query: snyk code test: "failed to upload files: request entity too large" on a monorepo

TL;DR: snyk code uploads your source for analysis, and monorepos blow past the upload size limit. Exclude the directories that do not need scanning (build output, vendored code, generated files) so the upload fits. If it still fails, scan one package at a time instead of the whole repo.

Not specified by the original author.

TL;DR

Huge SARIF reports overflow the agent's context. Do not feed the raw report; aggregate it into counts by rule and path, then give the agent the summary plus samples.

Error

agent failed to parse the gitleaks report: sarif too large, context overflow error

Steps

1. Confirm size is the issue: the report parses fine with tools but not in context. Expected: size, not corruption.
2. Aggregate the SARIF into a compact summary: findings per rule, per path, top examples. Expected: a summary that fits.
3. Feed the agent the summary plus a bounded sample of full findings. Expected: the agent can reason.
4. Let the agent request specific slices (one rule, one directory) on demand. Expected: drill-down without overload.
5. Stream future reports through the summarizer by default. Expected: no more overflows.

When to use

• Agents choking on large SARIF reports.
• Building report-consuming agents.

When not to use

• Malformed SARIF (fix the report).
• Small reports (feed directly).

Tool compatibility

• SARIF reports; summarization pipelines.

Variant phrasings

sarif too large for agent

Summarize first.

context overflow on report

Aggregate.

Why it happens

SARIF is verbose; a large repo's full report is megabytes, far beyond context windows.

Edge cases

• Summaries must preserve enough detail to act; counts alone are not triageable.
• Sampling must be deterministic for reproducible runs.
• The full report stays on disk for the agent to query by slice.

Provenance

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

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

Thread query: agent failed to parse the gitleaks report: sarif too large, context overflow error

TL;DR: Huge SARIF reports overflow the agent's context. Do not feed the raw report; aggregate it into counts by rule and path, then give the agent the summary plus samples.