Which client?
All / shared core
The problem
When a connected server starts rate-limiting requests, the Inspector currently just shows the raw error/timeout, without any recognition that a batch of failures might be rate-limit-shaped (e.g. repeated 429s or a consistent latency cliff), leaving distinguishing 'server down' from 'server throttling' up to the user.
Solution you have in mind (optional)
Recognize common rate-limit signals (429 status, Retry-After header) and surface a specific, actionable message with the retry timing instead of a generic error. Flagging as a discussion since it touches error-handling UX across all three clients.
Alternatives or workarounds you have tried
No response
Already built it locally?
No response
Before you submit
Which client?
All / shared core
The problem
When a connected server starts rate-limiting requests, the Inspector currently just shows the raw error/timeout, without any recognition that a batch of failures might be rate-limit-shaped (e.g. repeated 429s or a consistent latency cliff), leaving distinguishing 'server down' from 'server throttling' up to the user.
Solution you have in mind (optional)
Recognize common rate-limit signals (429 status, Retry-After header) and surface a specific, actionable message with the retry timing instead of a generic error. Flagging as a discussion since it touches error-handling UX across all three clients.
Alternatives or workarounds you have tried
No response
Already built it locally?
No response
Before you submit