The page reports a NetworkError rejection each time a background fetch fails #219

New Issue

rays · 2026-10-13T05:11:31-07:00

rays commented

2026-10-13 05:11:31 -07:00

The page reported 9 unhandled promise rejections to /api/client over 7 days, all from one Firefox on a Mac (rays@sdf1.net), from 2026-10-12 02:33 onwards: 8 were NetworkError when attempting to fetch resource. and 1, at 2026-10-12 15:08 (the overload), was a whole Cloudflare 502: Bad gateway HTML page used as the error message. src and line are empty, so the minified script does not say which call it was.

Somewhere a fetch that fails (the network dropping, a laptop waking, Cloudflare answering 502) is not caught, and an error built from a non-JSON response body carries the whole HTML page. Both should be caught and shown as a short message, the way other failed requests are.

A second thing visible in the same reports: three of them (02:35, 11:32 and 11:34 on 2026-10-13) carry the same trace id, d963583336ccc26ea5c4a9103743ba04, as do the /api/feeds, /api/entries, /api/me and /api/settings requests around them. Background requests nine hours apart are filed under one old tap, so the trace says the tap took nine hours.

$Q logs '{container="iPX"} |= "\"target\":\"ipx::client\"" |= "rejection" | json | line_format "{{.timestamp}} {{.msg}} {{.trace_id}}"' 7d
$Q trace d963583336ccc26ea5c4a9103743ba04

The page reported 9 unhandled promise rejections to `/api/client` over 7 days, all from one Firefox on a Mac (rays@sdf1.net), from 2026-10-12 02:33 onwards: 8 were `NetworkError when attempting to fetch resource.` and 1, at 2026-10-12 15:08 (the overload), was a whole Cloudflare `502: Bad gateway` HTML page used as the error message. `src` and `line` are empty, so the minified script does not say which call it was. Somewhere a fetch that fails (the network dropping, a laptop waking, Cloudflare answering 502) is not caught, and an error built from a non-JSON response body carries the whole HTML page. Both should be caught and shown as a short message, the way other failed requests are. A second thing visible in the same reports: three of them (02:35, 11:32 and 11:34 on 2026-10-13) carry the same trace id, `d963583336ccc26ea5c4a9103743ba04`, as do the `/api/feeds`, `/api/entries`, `/api/me` and `/api/settings` requests around them. Background requests nine hours apart are filed under one old tap, so the trace says the tap took nine hours. ``` $Q logs '{container="iPX"} |= "\"target\":\"ipx::client\"" |= "rejection" | json | line_format "{{.timestamp}} {{.msg}} {{.trace_id}}"' 7d $Q trace d963583336ccc26ea5c4a9103743ba04 ```

rays added the bug label 2026-10-13 05:11:31 -07:00

rays referenced this issue from a commit

2026-10-13 05:16:53 -07:00

Page: catch background fetches, no HTML in errors, a trace ends after a quiet minute (#219)

rays commented

2026-10-13 05:17:35 -07:00

Fixed in 724764c: the live update's list refresh and the first feed load catch a failed fetch, an HTML error page (Cloudflare's 502) gives the status as the message instead of the page, and a trace ends after a minute without a request, so background requests start their own. Deployed in ipx-web.

Fixed in 724764c: the live update's list refresh and the first feed load catch a failed fetch, an HTML error page (Cloudflare's 502) gives the status as the message instead of the page, and a trace ends after a minute without a request, so background requests start their own. Deployed in ipx-web.

rays closed this issue

2026-10-13 05:17:35 -07:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rays/ipx#219