Retry on partial live branch connections responses instead of showing partial results#1275
Retry on partial live branch connections responses instead of showing partial results#1275bwarminski wants to merge 6 commits into
Conversation
A 200 response that flags an instance unreachable is a transient fan-out failure under load. Retry within the existing retry budget and fall back to the partial list on exhaustion, rather than surfacing the degraded result on the first poll.
When the client's retries can't clear a partial-instance failure, the TUI holds the last good frame and lets the staleness dot and captured age surface it, instead of replacing good data with the unreachable banner. First load (no prior frame) still shows the partial. Shared HasUnreachableInstance moves onto ConnectionList.
Selecting a row in the detail view's blocker tree prepended a caret and shifted the row text, a layout jump the table view doesn't have. Pad unselected rows by the caret width so the text stays put on selection.
The default (Postgres) view rendered via lgtable, which distributes the terminal width across columns and spreads them with large gaps when the content (notably the trailing QUERY column) is short. Route it through the same content-based width + manual padding layout the Vitess/processlist view already used (generalized to tightColumnWidths / renderTightRow), so columns stay packed at the left regardless of terminal width.
Remove the always-true i>=0 guard in the tight table renderer (carried over from the old lgtable header-sentinel path) and the redundant consecutiveErrors==0 assertion in the first-load partial test (the view assertions already cover that branch).
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 179b666. Configure here.
| // Retry locally; the response carries no Retry-After hint. | ||
| partial, havePartial = list, true | ||
| retryAfter = 0 | ||
| case isTimeoutError(err) && ctx.Err() != nil: |
There was a problem hiding this comment.
Timeout drops saved partial list
Medium Severity
After a partial 200 is stored for retry, the overall List timeout can fire either while waiting between attempts or inside tryList. The wait path returns the saved partial with a nil error, but the in-flight timeout path always returns a timeout error and discards havePartial, so callers see a failed refresh instead of the degraded snapshot the PR intends.
Reviewed by Cursor Bugbot for commit 179b666. Configure here.


This fixes a couple of rough edges:
Old:

New:

Tested locally with a QA run on an overloaded server.