fix(desktop): retry the plan lookup and name the timeout that reaches users - #87
Merged
Merged
Conversation
… users Two gaps found while tracing a user-visible "fetch failed (UND_ERR_CONNECT_TIMEOUT | ...)" back to its source. The billing plan lookup called fetch directly, bypassing apiFetch and its retries, then failed closed to 'free'. Failing closed is right, but without a retry a single transient connect timeout downgrades a paying user to YouTube-only for the length of the cache. It now goes through apiFetch, so a blip is ridden out rather than billed as a failure. UND_ERR_CONNECT_TIMEOUT also had no entry in FRIENDLY_CODES, which is backwards: apiFetch retries it, so a user only ever sees it once the retries are spent, making it the code most likely to be read and the one with the least to read. The retryable codes now all carry friendly text, as does the headers timeout, which is not retried (the request was already sent) but surfaces the same way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RJFxocQAFeUPNW7oMNwe6e
ThreatCrush Security Scan72 finding(s) HIGH/CRITICAL: 13 | MEDIUM: 41 | LOW: 18
…and 22 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
ralyodio
added a commit
that referenced
this pull request
Aug 29, 2026
`pnpm format:check` runs over the whole repo, so these three files have been failing the Lint job on every open PR regardless of what that PR touched -- including #87, which only changes files under apps/desktop. Formatting only: prettier --write on the three files it named. No behaviour change. Claude-Session: https://claude.ai/code/session_013FGWJHRL6B6ExLg25UenBS Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
ralyodio
added a commit
that referenced
this pull request
Aug 29, 2026
…90) `usePointerLock` suppresses the mousemove that Chromium pairs with a pointermove by checking `performance.now() - lastPointerMoveAt < 16`. The test dispatches the pair on consecutive lines and expects the second to be dropped. That makes real elapsed time part of the assertion. On a loaded CI runner more than 16ms can pass between those two dispatches, the mousemove is taken as a second movement, and the pointer reads 0.7 instead of 0.6 -- a red build with nothing wrong in the code. It failed exactly this way on PR #87, which touches only apps/desktop, while the identical desktop copy of the test passed in the same run. Freezes performance.now across the paired dispatch in both copies. Confirmed by running the same test with a clock stepping 20ms per call, which reproduces the CI diff exactly (0.7 vs 0.6). Nothing that ships changes -- the 16ms window is still the shipped behaviour, it just is not a race in the test any more. Claude-Session: https://claude.ai/code/session_013FGWJHRL6B6ExLg25UenBS Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Traced a user-visible
fetch failed (UND_ERR_CONNECT_TIMEOUT | Connect Timeout Error (attempted address: pairux.com:443, timeout: 10000ms))back to its source. The site itself was healthy throughout — 15/15 probes returned 200 via the Railwayjfk1edge — so this is about how the desktop app handles a network path that stalls.Two gaps turned up on the way.
The billing plan lookup bypassed the retry layer.
entitlement.tscalledfetchdirectly instead ofapiFetch, then fell back to'free'on any error. Failing closed is the right call and stays. But with no retry underneath it, one transient connect timeout silently downgrades a paying user to YouTube-only for the length of the cache, with only aconsole.warnto show for it. It now goes throughapiFetch, so a blip gets ridden out rather than billed as a failure.UND_ERR_CONNECT_TIMEOUThad no friendly text. That is backwards:apiFetchretries this code, so a user only ever sees it once the retries are spent — roughly 33 seconds of failed connects. It is simultaneously the code most likely to be read and the one with the least to read. Every retryable code now carries friendly text, plusUND_ERR_HEADERS_TIMEOUT, which is deliberately not retried (the request was already sent, so a POST can't be replayed safely) but surfaces through the same path.A regression test pins the exact error shape from the original report.
Checks
The pre-commit hook was bypassed — its parallel turbo fan-out OOMs on this box. The gates were run individually instead, all green:
pnpm --filter @pairux/desktop typecheckpnpm --filter @pairux/desktop lintnpx vitest runinapps/desktop— 610 tests across 58 files, all passingpnpm --filter @pairux/desktop build🤖 Generated with Claude Code
https://claude.ai/code/session_01RJFxocQAFeUPNW7oMNwe6e