The decision half of the stale-token retry, kept free of the ajax transport so it can be
unit-tested (:node-test has no XMLHttpRequest, so anything requiring ajax.core is
untestable there — the same reason sse.cljc is separate).
The decision half of the stale-token retry, kept free of the ajax transport so it can be unit-tested (`:node-test` has no XMLHttpRequest, so anything requiring `ajax.core` is untestable there — the same reason `sse.cljc` is separate).
(reload-before-reopen? reason)Must the token be reloaded before re-opening an SSE stream the server closed with this
reconnect reason?
token-expired and subscriber-dropped are recovered by re-opening — the client's token
provider already holds a usable token in both cases. token-stale is not: the re-open
re-reads the SAME token, the server refuses it again, the connection closes, and the
backoff turns into a hot loop against a credential that will never become valid.
Must the token be reloaded before re-opening an SSE stream the server closed with this `reconnect` reason? `token-expired` and `subscriber-dropped` are recovered by re-opening — the client's token provider already holds a usable token in both cases. `token-stale` is not: the re-open re-reads the SAME token, the server refuses it again, the connection closes, and the backoff turns into a hot loop against a credential that will never become valid.
(reload-token!)The single in-flight token reload, as a channel. Concurrent stale requests park on the same promise-chan instead of each firing their own refresh — a burst of parallel requests right after a project is created would otherwise be a refresh storm.
The registered handler must not itself issue a request that can come back token-stale,
or it would park on the reload it is inside. /api/bff/refresh mounts no auth middleware
and cannot, which is what makes this safe.
The single in-flight token reload, as a channel. Concurrent stale requests park on the same promise-chan instead of each firing their own refresh — a burst of parallel requests right after a project is created would otherwise be a refresh storm. The registered handler must not itself issue a request that can come back `token-stale`, or it would park on the reload it is inside. `/api/bff/refresh` mounts no auth middleware and cannot, which is what makes this safe.
The one 401 — and the one SSE reconnect reason — that means "reload your token and
retry" rather than "log in again". One string, both transports.
The one 401 — and the one SSE `reconnect` reason — that means "reload your token and retry" rather than "log in again". One string, both transports.
(token-stale-401? result)Is this execute result the server saying the token is merely out of date?
cljs-ajax puts the parsed body of a FAILED request under [:data :response], not [:data] —
the app-side accessor is storage.web.api.response/reason; this module cannot require it,
so the one read is spelled out here.
Is this `execute` result the server saying the token is merely out of date? cljs-ajax puts the parsed body of a FAILED request under [:data :response], not [:data] — the app-side accessor is `storage.web.api.response/reason`; this module cannot require it, so the one read is spelled out here.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |