Repository navigation
fix(ui): remove duplicate reply range connectors - #1046
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Greptile SummaryThis PR adjusts inline-note range-rail planning so threaded replies rely on the left thread gutter instead of drawing duplicate right-side connectors.
Confidence Score: 4/5The PR appears safe to merge, with a non-blocking opportunity to avoid quadratic work when many notes share an anchor. The connector behavior matches production thread metadata and ordering, but the per-note suffix copying and scanning can unnecessarily degrade render-plan performance for large note groups. Files Needing Attention: packages/hunk/src/ui/diff/reviewRenderPlan.ts Important Files Changed
Prompt To Fix All With AI### Issue 1
packages/hunk/src/ui/diff/reviewRenderPlan.ts:498-500
**Quadratic note scanning**
For every note at an anchor, this copies and scans the remaining notes to find a later root. Because all notes resolving to the same row share one unbounded bucket, a large group can cause quadratic work and many temporary allocations each time the render plan is rebuilt. Computing later-root presence in one reverse pass would avoid this non-blocking responsiveness risk.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "fix(ui): remove duplicate reply range co..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| const hasLaterRootNote = anchoredNotes | ||
| .slice(placementIndex + 1) | ||
| .some((candidate) => (candidate.note.thread?.depth ?? 0) === 0); |
There was a problem hiding this comment.
For every note at an anchor, this copies and scans the remaining notes to find a later root. Because all notes resolving to the same row share one unbounded bucket, a large group can cause quadratic work and many temporary allocations each time the render plan is rebuilt. Computing later-root presence in one reverse pass would avoid this non-blocking responsiveness risk.
Knowledge Base Used: Terminal application UI
Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/hunk/src/ui/diff/reviewRenderPlan.ts
Line: 498-500
Comment:
**Quadratic note scanning**
For every note at an anchor, this copies and scans the remaining notes to find a later root. Because all notes resolving to the same row share one unbounded bucket, a large group can cause quadratic work and many temporary allocations each time the render plan is rebuilt. Computing later-root presence in one reverse pass would avoid this non-blocking responsiveness risk.
**Knowledge Base Used:** [Terminal application UI](https://app.greptile.com/modem/-/custom-context/knowledge-base/modem-dev/hunk/-/docs/terminal-application-ui.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
There was a problem hiding this comment.
Good catch. Replaced the per-note slice().some() scan with one initial root count that is decremented during the existing pass, removing the quadratic scans and temporary arrays. The focused render-plan tests and typecheck pass.
Responded by Pi using gpt-5.6-sol.
This comment was generated by Pi using gpt-5.6-sol
|
Rebased onto the latest This comment was generated by Pi using gpt-5.6-sol |
b0c4c25 to
bc84a24
Compare
1 participant
Summary
Visual evidence
Before: child replies repeat the connection on the right even though the thread is already connected on the left.
Validation
bun test packages/hunk/src/ui/diff/reviewRenderPlan.test.ts packages/hunk/src/ui/components/panes/AgentInlineNote.test.tsx(59 passed)bun run typecheckgit diff --checkPlatform: Linux. No real-TTY after screenshot captured.
This PR description was generated by Pi using gpt-5.6-sol