perf(grouping): return file indices instead of paths - #1209
Merged
Merged
Conversation
The grouping LLM call asked the model to echo full file paths back in its JSON response, making the output size proportional to the sum of all path lengths. On large change sets this overflowed the completion token limit; the truncated JSON then failed to parse and the whole change set degraded to per-file dispatch, multiplying downstream review calls. Switch the grouping contract to integer indices: - buildFileList prefixes each file with a zero-based index, e.g. "[0] MODIFIED path (+12/-3)". - groupingResponse.Files is now []int; the model returns those indices. - parseGroupingResponse maps indices back to diffs by position, skipping out-of-range indices (the index equivalent of the previous unknown-path skip) and duplicates. A parse failure still returns an error and the caller falls back to per-file dispatch, exactly as before. - Prompts updated to ask for integer indices. The response is now an order of magnitude smaller, so truncation on large change sets becomes rare instead of common. Because the grouping response is now indices, the session viewer resolves them back to paths for display: - buildGroupingIndex scans the request's numbered file list (user message only) to build an index->path map. - parseGroupingGroups unmarshals the response into indices; a legacy path-string response reports not-ok so the viewer keeps showing the raw text (already readable for those older sessions). - groupingView maps indices to paths and falls back to the raw response when nothing resolves (format drift), avoiding a wall of "#idx". - The grouping card renders label + resolved paths with a collapsible raw response for audit. No on-disk format changes; existing sessions render retroactively.
Contributor
|
✅ OpenCodeReview: Review complete: 0 finding(s) across 5 selected item(s). |
…dices # Conflicts: # internal/viewer/store.go
stay-foolish-forever
approved these changes
Sep 12, 2026
10 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The grouping LLM call asked the model to echo full file paths back in its JSON response, so the output size grew with the sum of all path lengths. On large change sets this overflowed the completion token limit; the truncated JSON then failed to parse and the whole change set degraded to per-file dispatch, multiplying downstream review calls. This is the main reason grouping was slow on big diffs.
What
Backend — grouping contract switched from paths to integer indices
buildFileListprefixes each file with a zero-based index, e.g.[0] MODIFIED path (+12/-3).groupingResponse.Filesis now[]int; the model returns those indices, e.g.[{"label":"...","files":[0,1]}].parseGroupingResponsemaps indices back to diffs by position, skipping out-of-range indices (the index equivalent of the previous unknown-path skip) and duplicates. A parse failure still returns an error and the caller falls back to per-file dispatch, exactly as before.The response is now an order of magnitude smaller, so truncation on large change sets becomes rare instead of common.
Viewer — resolve indices back to paths for display
Because the grouping response is now indices, the session viewer renders them as paths:
buildGroupingIndexscans the request's numbered file list (user message only) to build an index→path map.parseGroupingGroupsunmarshals the response into indices; a legacy path-string response reports not-ok so the viewer keeps showing the raw text (already readable for those older sessions).groupingViewmaps indices to paths and falls back to the raw response when nothing resolves (format drift), avoiding a wall of#idx.No on-disk format changes; existing sessions render retroactively.
Scope notes
Testing
go build ./...andgo vet ./...pass.internal/agentandinternal/viewertest suites pass, covering index parsing, out-of-range/duplicate handling, index→path resolution, format-drift fallback, and end-to-end viewer rendering.