Greptile Summary

This PR prevents large files from freezing the UI during inline context expansion by capping source reads at 1 MB across all three source kinds (filesystem, git-blob, git-index), killing over-limit git show subprocesses while streaming rather than buffering the whole blob first, and surfacing a clear "Source too large to expand" label in collapsed gap rows.

• fileSource.ts: Introduces SourceTextTooLargeError, DEFAULT_SOURCE_TEXT_MAX_BYTES, and readStreamTextWithLimit — a streaming reader that kills the subprocess and throws as soon as the byte budget is exceeded.
• expandCollapsedRows.ts / useReviewController.ts: Threads the reason: \"too-large\" discriminant through the FileSourceStatus error variant so the UI can display a distinct, actionable label instead of the generic "Could not load" message.
• Tests: Adds regression coverage for the cap at the unit, integration, and hook levels.

Confidence Score: 4/5

Safe to merge — the cap correctly prevents memory exhaustion and the UI path is well-covered by new tests; two minor logic gaps are worth addressing in a follow-up.

The streaming kill logic, the fs size-check, and the new UI label all work correctly and are tested end-to-end. Two issues are worth noting: the toggleGap skip-fetch guard doesn't include the too-large terminal state, so every subsequent gap interaction on an over-limit file spawns and immediately kills a fresh git show subprocess; and a SourceTextTooLargeError thrown from the 64 KB stderr reader would be misreported as 'source too large' even when the actual source content was within budget. Neither issue causes data loss or a crash, but both are real misbehaviors on the changed paths.

src/core/fileSource.ts and src/ui/hooks/useReviewController.ts warrant a second look for the two logic gaps described in the inline comments.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[toggleGap called] --> B{currentStatus?}
    B -- loaded / loading --> C[Skip fetch — return early]
    B -- error / undefined --> D[Spawn source load request]
    D --> E[file.sourceFetcher.getFullText]
    E --> F{Result?}
    F -- text !== null --> G[setSettledStatus loaded]
    F -- text === null --> H[setSettledStatus error]
    F -- throws SourceTextTooLargeError --> I[setSettledStatus error reason=too-large]
    F -- throws other error --> J[console.error + setSettledStatus error]

    subgraph fileSource.ts
        K[readFsSpec] --> L{file.size > maxBytes?}
        L -- yes --> M[throw SourceTextTooLargeError]
        L -- no --> N[Bun.file.text]

        O[readGitObjectSpec] --> P[git show subprocess]
        P --> Q[readStreamTextWithLimit stdout]
        Q --> R{totalBytes > maxBytes?}
        R -- yes --> S[proc.kill + throw SourceTextTooLargeError]
        R -- no --> T[accumulate chunks → decode]
    end

    E -.-> K
    E -.-> O

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
src/ui/hooks/useReviewController.ts:440-443
**Too-large status not treated as terminal — redundant re-fetches on every toggle**

The skip-fetch guard only bails out for `"loaded"` and `"loading"`, but not for `{ kind: "error", reason: "too-large" }`. Once a file has been identified as over-limit, every subsequent call to `toggleGap` (collapsing, re-opening, or opening a different gap in the same file) passes the guard and spawns a brand-new `git show` subprocess that streams up to 1 MB before being killed — an expensive operation guaranteed to fail identically each time. The fix is to also short-circuit when the settled status is a permanent "too-large" error.

### Issue 2 of 2
src/core/fileSource.ts:186-201
**`SourceTextTooLargeError` from stderr reader surfaces as wrong UI message**

Both stdout and stderr reads share the same `SourceTextTooLargeError` type, and the catch block re-throws any instance of it without distinguishing which stream originated it. If `git show` writes more than 64 KB to stderr (e.g., hook output, verbose trace logging), the error from the stderr `readStreamTextWithLimit` call will be caught and re-thrown, causing the caller to display "Source too large to expand" even though the actual source content may have been well within the 1 MB limit. The stderr overflow should instead be treated as a generic read failure (logged and return `null`) rather than mapped to `SourceTextTooLargeError`.

_{Reviews (1): Last reviewed commit: "fix(ui): cap expanded context source rea..." | Re-trigger Greptile}