Anton Panasenko d047c33a1b fix(remote-control): avoid server token refresh retry storms (#30201) ...

## Why

Remote-control websocket reconnects and pairing requests proactively
refresh their server token. When `/server/refresh` returns a transient
error such as `502`, the still-valid token was discarded as a usable
connection path, causing reconnect failures and repeated refresh
attempts that could amplify an upstream incident.

## What Changed

- Start proactive refresh five minutes before token expiry and
distinguish it from a required refresh for missing or expired tokens.
- Continue websocket and pairing operations with the existing valid
token after `429`, `5xx`, or timeout failures.
- Share an in-memory `next_refresh_at` throttle across websocket and
pairing callers, honoring both `Retry-After` formats and otherwise using
a jittered 24–36 second delay.
- Keep required refreshes strict, preserve `404` enrollment replacement,
and clear token/throttle state for `401` and `403` auth recovery.
- Preserve refresh response metadata internally and add focused
wire-level and integration coverage.

## Verification

Added behavioral coverage proving that:

- a valid near-expiry token still completes websocket and pairing
requests after transient refresh failures;
- `Retry-After` suppresses a subsequent refresh across websocket and
pairing callers;
- request and response-body timeouts are classified as transient;
- an expired token, including one that expires during refresh, cannot
proceed to websocket connection;
- auth failures clear the attempted token without overwriting a
concurrently rotated token.

d047c33a1b · 2026-06-26 17:34:52 -07:00

History

..

src

fix(remote-control): avoid server token refresh retry storms (#30201)

2026-06-26 17:34:52 -07:00

BUILD.bazel

app-server: move transport into dedicated crate (#20545)

2026-05-01 09:23:47 -07:00

Cargo.toml

fix(remote-control): avoid server token refresh retry storms (#30201)

2026-06-26 17:34:52 -07:00