Problem
DeviceCodeAuthProvider.pollForTokens loops until startTime + this.timeout (15 min). When BMW's token endpoint returns 5xx, the v1.0.24 change (lib/auth/DeviceCodeAuthProvider.ts:312) logs a warning, bumps the poll interval up to 30 s, and keeps trying for the full 15 minutes. There is no cap on consecutive 5xx responses.
If BMW's token endpoint is genuinely broken, the user sees "Waiting for authorisation…" for 15 minutes with no feedback, then a generic timeout. Worse, the device-code itself is only valid for 5 minutes (BMW's expires_in), so after minute 5 we are polling with a dead code and BMW will start returning expired_token anyway — but transient 5xx during that window prevents us from learning that.
Proposal
Add a maxConsecutive5xx cap (e.g. 5). On exceeding the cap, fail loudly with an AuthenticationError carrying the HTTP status, correlation id, and last response body. User gets a clear actionable toast instead of a silent 15-minute wait.
Keep the existing exponential interval bump as a soft signal, but bound the loop with the new counter so we exit predictably.
Acceptance
- New unit test: simulate 5 consecutive 5xx →
pollForTokens rejects with AuthenticationError within seconds (no 15-min wait).
- Existing test: single 5xx followed by
200 still succeeds.
- Existing test:
authorization_pending loop still polls until success or expired_token.
Related
Deferred from v1.0.25 root-cause analysis (issue #108 cluster). Belt-and-braces for the original 1.0.23 fail-loud regression that v1.0.24 partially addressed.
Problem
DeviceCodeAuthProvider.pollForTokensloops untilstartTime + this.timeout(15 min). When BMW's token endpoint returns 5xx, the v1.0.24 change (lib/auth/DeviceCodeAuthProvider.ts:312) logs a warning, bumps the poll interval up to 30 s, and keeps trying for the full 15 minutes. There is no cap on consecutive 5xx responses.If BMW's token endpoint is genuinely broken, the user sees "Waiting for authorisation…" for 15 minutes with no feedback, then a generic timeout. Worse, the device-code itself is only valid for 5 minutes (BMW's
expires_in), so after minute 5 we are polling with a dead code and BMW will start returningexpired_tokenanyway — but transient 5xx during that window prevents us from learning that.Proposal
Add a
maxConsecutive5xxcap (e.g. 5). On exceeding the cap, fail loudly with anAuthenticationErrorcarrying the HTTP status, correlation id, and last response body. User gets a clear actionable toast instead of a silent 15-minute wait.Keep the existing exponential interval bump as a soft signal, but bound the loop with the new counter so we exit predictably.
Acceptance
pollForTokensrejects withAuthenticationErrorwithin seconds (no 15-min wait).200still succeeds.authorization_pendingloop still polls until success orexpired_token.Related
Deferred from v1.0.25 root-cause analysis (issue #108 cluster). Belt-and-braces for the original 1.0.23 fail-loud regression that v1.0.24 partially addressed.