Stop cutting Query Store errors before the status bar can trim them - #452
Conversation
Same family as #448, different surface. QueryStore.cs cut the message to 80 characters and appended an ellipsis before handing it to StatusText, which already has TextTrimming="CharacterEllipsis". The trimming is the control's job and it does it against the actual available width; doing it again in code threw away text the control would otherwise have kept. It also cost the only way to recover the rest. The bar is one line, so a long message is readable on hover or not at all - SetStatus now sets the tip to the full text, which costs nothing when the message fits and is the difference between a truncated error and a recoverable one when it does not. That applies to every status, not just this one, because every status goes through the same bar with the same one-line constraint. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
| /* The bar is one line and trims with an ellipsis, so a long message - an error, usually - | ||
| is readable only on hover. Setting the tip to the same text costs nothing when it fits and | ||
| is the difference between a truncated error and a recoverable one when it does not. */ | ||
| ToolTip.SetTip(StatusText, string.IsNullOrEmpty(text) ? null : text); |
There was a problem hiding this comment.
This sets the tooltip whenever SetStatus is called, but the 3-second auto-clear a few lines below only resets StatusText.Text = "" — it never calls ToolTip.SetTip(StatusText, null). So after an auto-clearing status message times out, the tooltip on the now-empty status bar still holds the previous (possibly long) text until the next SetStatus call overwrites it. Since this PR's whole point is "let people recover the full message via hover," the stale tip should probably be cleared in that same Dispatcher.UIThread.Post callback below.
|
Reviewed the diff ( One correctness gap flagged inline: the 3-second auto-clear timer in |
The defect erikdarlingdata#452 fixed at the session-level Query Store site, fixed at the five sites that still had it: two fetch paths, the metric refresh, the database check, and the time slicer all cut exception text to 60-80 characters + "..." before handing it to StatusText. The interesting half of a SQL error - the login failure, the firewall hint - is rarely in its first 60 characters, and the cut threw it away for good. The sites now pass the full message, and the strip mirrors whatever it shows into its tooltip, which is erikdarlingdata#452's recovery path. One PropertyChanged subscription in the constructor rather than a tooltip set at each error site: this control writes StatusText from a dozen places across five partials, and a tip set only on errors would go stale the moment "Fetching plans..." overwrote the text but not the tip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PvAv72Pwb8czsjDWsCCk7n
Same family as #448, different surface — the loose end I flagged when that merged.
QueryStore.cscut the message to 80 characters and appended an ellipsis before handing it toStatusText, which already hasTextTrimming="CharacterEllipsis". The trimming is the control's job and it does it against the actual available width; doing it again in code threw away text the control would otherwise have kept.It also cost the only way to recover the rest. The bar is one line, so a long message is readable on hover or not at all —
SetStatusnow sets the tip to the full text. That costs nothing when the message fits, and is the difference between a truncated error and a recoverable one when it doesn't. It applies to every status rather than just this one, because every status goes through the same bar under the same one-line constraint.🤖 Generated with Claude Code