Skip to content

fix(F4): stream-read large files instead of 10MB hard cap - #79

Merged
yogthos merged 1 commit into
mainfrom
fix/f4-read-streaming
May 21, 2026
Merged

fix(F4): stream-read large files instead of 10MB hard cap#79
yogthos merged 1 commit into
mainfrom
fix/f4-read-streaming

Conversation

@yogthos

@yogthos yogthos commented May 21, 2026

Copy link
Copy Markdown
Collaborator

Track F-HIGH #4. read no longer refuses files >10MB; streams via BufReader with per-line cap (16KB) and a 1GB file safety net. 2 new tests, 658 pass.

Track F-HIGH #4 from ROADMAP.md.

## Problem

`read.rs:91-98` rejected files >10MB outright with
`File too large (N bytes). Max 10MB.` Agents couldn't sample
large logs, generated outputs, build artifacts, or test fixtures.
Workaround was a bash `head`/`tail` invocation, which obscures
intent and skips the LSP warmup that read provides.

## Fix

Replace eager `tokio::fs::read_to_string` with a streaming
`tokio::io::BufReader::lines()`:

- Stream line-by-line, tracking total count for the header.
- Truncate any individual line longer than `MAX_LINE_BYTES = 16384`
  to defend against pathological minified-JS / accidental binary
  reads. UTF-8 boundary-safe truncation; trailing
  ` …[line truncated]` marker so the LLM sees the cut.
- Keep an excerpt buffer of just `[offset, offset+limit)` lines —
  doesn't grow with file size.
- New safety net: `MAX_FILE_BYTES = 1GB`. Beyond that we still
  refuse but the error suggests bash + head/tail/grep instead.

Matches opencode's `read.ts:119-150` stream + early-terminate
shape and pi's `read.ts:215-328` smart truncation.

## Tests

Two new tests in `agent::tools::read::tests`:

- `read_truncates_pathological_long_lines`: writes a file with a
  100KB single line plus normal lines; asserts the long line is
  truncated with the marker and total output is <100KB.
- `read_handles_files_larger_than_old_10mb_cap`: 1MB fixture
  (10k × 99-byte lines); asserts read succeeds, header shows
  the true total line count, and the excerpt is just the
  requested 5 lines.

656 → 658 pass. All build profiles clean.
@yogthos
yogthos merged commit 93c80e5 into main May 21, 2026
1 check passed
@yogthos
yogthos deleted the fix/f4-read-streaming branch May 21, 2026 04:15
allen-munsch pushed a commit to allen-munsch/dirge that referenced this pull request Jun 3, 2026
)

Track F-HIGH #4 from ROADMAP.md.

## Problem

`read.rs:91-98` rejected files >10MB outright with
`File too large (N bytes). Max 10MB.` Agents couldn't sample
large logs, generated outputs, build artifacts, or test fixtures.
Workaround was a bash `head`/`tail` invocation, which obscures
intent and skips the LSP warmup that read provides.

## Fix

Replace eager `tokio::fs::read_to_string` with a streaming
`tokio::io::BufReader::lines()`:

- Stream line-by-line, tracking total count for the header.
- Truncate any individual line longer than `MAX_LINE_BYTES = 16384`
  to defend against pathological minified-JS / accidental binary
  reads. UTF-8 boundary-safe truncation; trailing
  ` …[line truncated]` marker so the LLM sees the cut.
- Keep an excerpt buffer of just `[offset, offset+limit)` lines —
  doesn't grow with file size.
- New safety net: `MAX_FILE_BYTES = 1GB`. Beyond that we still
  refuse but the error suggests bash + head/tail/grep instead.

Matches opencode's `read.ts:119-150` stream + early-terminate
shape and pi's `read.ts:215-328` smart truncation.

## Tests

Two new tests in `agent::tools::read::tests`:

- `read_truncates_pathological_long_lines`: writes a file with a
  100KB single line plus normal lines; asserts the long line is
  truncated with the marker and total output is <100KB.
- `read_handles_files_larger_than_old_10mb_cap`: 1MB fixture
  (10k × 99-byte lines); asserts read succeeds, header shows
  the true total line count, and the excerpt is just the
  requested 5 lines.

656 → 658 pass. All build profiles clean.

Co-authored-by: Yogthos <yogthos@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant