Latest-attempt filter, and the retry chains on the dashboard - #298
Conversation
A chain is one piece of work however many attempts it took, so a list of failures otherwise shows one problem as many rows. LatestOnly narrows it to where each chain got to — an anti-join on the indexed RetryFor, shared with bulk retry, which then has nothing left to substitute. The dashboard's summary adds the two things a count of failures cannot say: which chains keep failing however often they are retried, and whether retrying achieves anything here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The "Failures to act on" tile counts problems where "failed today" counts attempts, and reads its number from the search so it agrees with the list it opens. The panel beside Latest failures says which chains are not getting better, with the retry success rate as the context that makes a long chain either bad luck or something to fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: simplify9/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (10)
📝 SummarySummary
Risk: Security-sensitive areas: Dashboard permission checks and query exposure. The change adds database queries and user-controlled filtering, but does not change authentication or authorization models. Test coverage: Adds 3 integration tests and 2 end-to-end specifications. Tests cover latest-attempt filtering, healed and superseded chains, retry metrics, dashboard counts, ranking, navigation, and URL persistence. Operational concerns: No migration is required. Query performance depends on the indexed WalkthroughAdds retry-chain metrics and failing-chain details to the dashboard. Adds a latest-attempt-only exchange filter across the API and web client. Extends integration and end-to-end tests for dashboard counts, chain ranking, filtering, navigation, and URL persistence. ChangesRetry dashboard observability
Latest-attempt exchange filtering
Estimated code review effort: 4 (Complex) | ~45 minutes Suggested labels: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2 participants
Follows #297. A retry chain is one piece of work however many attempts it took, which the UI had no way of saying — so a list of failures showed one problem as many rows, and the dashboard counted attempts where someone wants problems.
Latest attempt only — a filter on the exchanges list for where each chain actually got to. On local data that is 1,025 failed attempts against 149 real failures. One predicate in the shared filter code, so bulk retry gets it too: selecting all failures on one subscription went from 90 selected → 84 substitutions → 6 retries to 6 selected → 6 retried, nothing substituted.
NOT EXISTSon the indexedRetryFor— the anti-join shape the still-running pill already uses there, for the reasons in that handler's comments.Failures to act on — a dashboard tile counting problems rather than attempts. Its number comes from the search rather than from the dashboard's own 14-day row fetch, so the tile and the list it opens cannot disagree (the same approach "Pending auto-retries" already takes).
Chains that keep failing — a panel for the chains that are not getting better however often they are retried, worst first, each row opening its chain. Its description carries the retry success rate, because a 34-attempt chain only means "broken" where retries normally succeed — on local data, 3 of 189 did.
XchangeResult.AttemptNumberalready stores chain depth, but only for failures a retry policy's group matched, so a hand-retried chain has none. Counted with a batched upward walk instead: one query per level for all candidates at once rather than a walk each, bounded to the 500 newest.Tested: 3 new integration tests, 2 new e2e specs, and verified by hand against local data.
🤖 Generated with Claude Code