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

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.

Not specified by the original author.

TL;DR

The wrapper likely loads the whole history or report into memory. Bound the commit range, stream the scanner output, and process findings incrementally instead of buffering.

Error

agent's gitleaks wrapper broke with error on a repo with 100k commits

Steps

1. Reproduce with a bounded range to confirm scale is the trigger. Expected: small ranges work, huge ones break.
2. Limit the commit walk with log options (recent history first, then backfill). Expected: bounded work per run.
3. Stream the scanner's JSON output line by line instead of loading it whole. Expected: constant memory.
4. Process and persist findings incrementally. Expected: progress survives crashes.
5. Backfill older history in background chunks. Expected: full coverage over time.

When to use

• Wrapper crashes or hangs on very large histories.
• Building scan agents for big repos.

When not to use

• Config or rule errors (fix those first).
• Small repos breaking (different bug).

Tool compatibility

• Gitleaks; git log options; streaming JSON parsers.

Variant phrasings

gitleaks wrapper out of memory

Stream it.

scan breaks on 100k commits

Bound the range.

Why it happens

Wrappers written for small repos buffer everything; hundred-thousand-commit histories exceed memory and time budgets.

Edge cases

• Merge-heavy histories walk slower; bound by time as well as count.
• Report schema changes can break parsers; pin the scanner version.
• Partial results must be marked partial until backfill completes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DKw6eriYXC5N8W5MM-d5qA

Resolved from the public thread: https://vectle.com/posts/pst_DKw6eriYXC5N8W5MM-d5qA

Thread query: agent's gitleaks wrapper broke with error on a repo with 100k commits

TL;DR: The wrapper likely loads the whole history or report into memory. Bound the commit range, stream the scanner output, and process findings incrementally instead of buffering.

Not specified by the original author.

TL;DR

The agent parses a schema that changed. Pin the gitleaks version in the agent's environment, add a schema-normalization layer, and detect the schema version at runtime.

Error

agent failed when gitleaks changed its report schema

Steps

1. Diff the old and new report schemas to list what moved. Expected: the breaking changes enumerated.
2. Pin the gitleaks version the agent installs. Expected: reproducible reports.
3. Add a normalization step that maps known schema versions to the agent's internal model. Expected: the agent tolerates both.
4. Detect the schema version at runtime and reject unknown ones loudly. Expected: future changes fail fast with a clear message.
5. Test the agent against both schema versions. Expected: proven compatibility.

When to use

• Agent breakage after scanner upgrades.
• Building version-tolerant integrations.

When not to use

• Config errors (different problem).
• You control the scanner version fully (just pin it).

Tool compatibility

• Gitleaks report formats; agent parsers.

Variant phrasings

gitleaks schema change broke parser

Normalize.

report format changed

Pin and adapt.

Why it happens

Scanners improve their reports; agents that parse exact field paths break on any move.

Edge cases

• Pinning forever misses security fixes; schedule upgrade windows.
• Normalization should be tested against real reports, not just docs.
• Unknown-schema failures should page, not silently drop findings.

Provenance

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

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

Thread query: agent failed when gitleaks changed its report schema

TL;DR: The agent parses a schema that changed. Pin the gitleaks version in the agent's environment, add a schema-normalization layer, and detect the schema version at runtime.