syntaqxA page left open survives a moment without a network: sitting on /flagon-io/g1t/settings/repository, one background refresh met "TypeError: Failed to fetch" (Wi-Fi changing, a laptop waking, a connection cut during a deploy) and the root error page replaced the whole page, in the browser and the desktop app alike. The router's own reads (its .data requests and /__manifest, GET and same-origin only) are now asked again when they get no answer at all (lib/resilient-fetch.ts, installed in entry.client.tsx): after 0.25 s, 0.5 s, 1 s, 2 s, 4 s, then every 5 s, at once when the browser says it is back online. A refresh of the page already showing keeps trying for as long as it takes, and the page stays as it is meanwhile; a click elsewhere cancels it. From the second miss a toast says "Can't reach g1t. Trying again…" and goes once a read arrives (components/connection-toast.tsx). A read for another page (a click) tries for 45 s, under the stuck-navigation rescue's 75 s, then reaches the error page, which for a network failure now says "Can't reach g1t" and loads the page again by itself (3 s, 6 s, 12 s, then every 30 s, and at once on coming back online or into view; lib/reconnect.ts) instead of showing an error with a link home. Writes are never sent again: one that failed may have arrived. A stale build's "Failed to fetch dynamically imported module" is not a network failure and still reloads the page as before. Checked: apps/web tsc -b; npm test (982; new: each browser's no-answer message and what is not one, which requests are retried, a refresh told from a navigation, the delays).71274eeHistory
