Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Fix cancel cursor + addressed stats in TUI#274

Merged
wesm merged 4 commits intomainfrom
little-tui-bugs
Feb 16, 2026
Merged

Fix cancel cursor + addressed stats in TUI#274
wesm merged 4 commits intomainfrom
little-tui-bugs

Conversation

@wesm
Copy link
Collaborator

@wesm wesm commented Feb 16, 2026 •
edited
Loading

Summary

Test plan

  • Enable hide-addressed (h), cancel a running job (x) — cursor should move to next visible job
  • Toggle addressed (a) on a job — status bar counts should update immediately
  • Toggle addressed from review view (a) — status bar counts should update on return to queue

Fixes #262, fixes #265.

🤖 Generated with Claude Code

@wesm @claude
Fix cursor disappearing on cancel with hide-addressed, update stats o…
aa2fcd0 
…n toggle

Cancel key (`x`) now adjusts cursor to the next visible job when
hide-addressed is active, matching the behavior of the addressed key.
Addressed toggle (`a`) now optimistically updates jobStats so the
status bar reflects changes immediately without waiting for the next
poll cycle. Both queue-view and review-view paths are covered.

Fixes #262, fixes #265.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@roborev-ci
Copy link

roborev-ci bot commented Feb 16, 2026

roborev: Combined Review

Verdict: ⚠️ One Medium issue was identified; no High/Critical findings.

Medium

  1. Optimistic jobStats updates are not rolled back on addressed-toggle API failure
    • Files/lines: cmd/roborev/tui_handlers.go:787, cmd/roborev/tui_handlers.go:809, cmd/roborev/tui_handlers.go:1298
    • Details: handleAddressedKey applies optimistic Addressed/Unaddressed counter changes, but in handleAddressedResultMsg error handling only addressed flags are reverted. The counters can drift (and potentially go negative) after repeated failed toggles until a later refresh reconciles state.
    • Suggested fix: In the current-request error rollback path, also invert the optimistic counter delta using msg.newState (true => Addressed--, Unaddressed++; false => Addressed++, Unaddressed--), with clamping at >= 0 if needed.

Synthesized from 4 reviews (agents: codex, gemini | types: security, default)

@wesm @claude
Roll back optimistic jobStats on addressed toggle API error
3804168 
The rollback handler restored the per-job addressed state but not the
status bar counters, leaving them drifted until the next poll. Now
reverses the stats delta on error alongside the job state rollback.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@roborev-ci
Copy link

roborev-ci bot commented Feb 16, 2026

roborev: Combined Review

Verdict: One Medium issue found; no Critical/High findings, and security reviews reported no issues.

Medium

  1. Potential double-rollback of optimistic stats can corrupt counters temporarily
    • Location: cmd/roborev/tui_handlers.go:1308
    • Issue: Rollback logic assumes the optimistic stats delta is still applied. If a periodic refresh (handleJobsMsg) overwrites m.jobStats before the error response arrives, the rollback can apply an extra inverse delta, causing incorrect (possibly negative) counts until the next poll.
    • Suggested fix: Track whether each pending toggle delta is still active (or reapply pending deltas after refresh) and only roll back when that delta is currently applied.

Synthesized from 4 reviews (agents: codex, gemini | types: security, default)

@wesm @claude
Re-apply pending addressed deltas after poll refresh
607f1e3 
When a jobs poll resets m.jobStats to server truth, pending optimistic
deltas were lost, causing subsequent error rollbacks to over-correct
(and potentially go negative). Now re-applies all pending addressed
deltas on top of server stats so rollback math stays consistent.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@roborev-ci
Copy link

roborev-ci bot commented Feb 16, 2026

roborev: Combined Review

Verdict: Medium-severity correctness issues were found in optimistic stats reconciliation; fix before merge.

Medium

  1. Potential double-counting of JobStats during poll reconciliation
    File/lines: cmd/roborev/tui_handlers.go:1110, cmd/roborev/tui_handlers.go:1112, cmd/roborev/tui_handlers.go:1113 (also reported as 1110-1123)
    Finding: handleJobsMsg reapplies optimistic pending deltas onto fresh server stats before (or without) reliably reconciling whether the server already reflects those state changes. This can temporarily over/under-count (e.g., addressed counted twice, unaddressed going negative).
    Suggested fix: Reconcile pending entries against fresh msg.jobs/server state first; only apply deltas for entries still truly pending and not already reflected.

  2. Delta computation can drift in rapid-toggle sequences
    File/lines: cmd/roborev/tui_handlers.go:1113
    Finding: Delta math is derived from pending.newState alone rather than serverState -> pending.newState. In rapid toggles (e.g., false -> true -> false around polls), counters can drift and become incorrect.
    Suggested fix: Compute delta per job from the current server-reported state to pending desired state, and apply only when they differ.

Synthesized from 4 reviews (agents: gemini, codex | types: security, default)

@wesm @claude
Fix double-counting of stats when poll confirms pending toggle
efd574b 
Pending reconciliation now runs before stats delta re-application so
confirmed entries are cleared first. Also extracts applyStatsDelta
helper to deduplicate the 4 inline increment/decrement blocks.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@roborev-ci
Copy link

roborev-ci bot commented Feb 16, 2026

roborev: Combined Review

Verdict: Changes are not clean; there is 1 merged High severity stats-synchronization bug that can miscount addressed/unaddressed totals.

High

  1. Pending addressed delta can be re-applied after server refresh, causing double-counted/incorrect stats
    • Locations: cmd/roborev/tui_handlers.go:1108, cmd/roborev/tui_handlers.go:1124, cmd/roborev/tui_handlers.go:1125, cmd/roborev/tui_handlers.go:1310
    • What’s happening: handleJobsMsg refreshes m.jobStats from msg.stats and then replays pending deltas. If the server response already reflects the toggle (or the toggled job is filtered out and pending state is never cleared), the same delta is applied again, leading to incorrect totals.
    • Why this is serious: UI stats can drift from server truth and remain wrong across polls.
    • Suggested fix: Clear pendingAddressed[msg.jobID] once a toggle is confirmed (including when job is absent from current msg.jobs due to filters), and only apply pending deltas for jobs whose server state is not yet reflected in the current poll payload.

Synthesized from 4 reviews (agents: codex, gemini | types: security, default)

@wesm wesm merged commit 41ab759 into main Feb 16, 2026
6 of 7 checks passed
@wesm wesm deleted the little-tui-bugs branch February 16, 2026 16:08
hughdbrown pushed a commit to hughdbrown/roborev that referenced this pull request Feb 16, 2026
@wesm @claude @hughdbrown
Fix cancel cursor + addressed stats in TUI (roborev-dev#274)
13ffa63 
## Summary

- Cancel key (`x`) now adjusts cursor to next visible job when
hide-addressed is active, preventing the cursor from landing on a hidden
row (roborev-dev#265)
- Addressed toggle (`a`) now optimistically updates the status bar stats
(addressed/unaddressed counts) immediately instead of waiting for the
next poll cycle (roborev-dev#262)
- Both queue-view and review-view addressed paths update stats

## Test plan

- [x] Enable hide-addressed (`h`), cancel a running job (`x`) — cursor
should move to next visible job
- [x] Toggle addressed (`a`) on a job — status bar counts should update
immediately
- [x] Toggle addressed from review view (`a`) — status bar counts should
update on return to queue

Fixes roborev-dev#262, fixes roborev-dev#265.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.6 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

1 participant

@wesm