Sync pill flips offline on an explicit OS false or a lost PowerSync connection

Inside that window the app also stopped trying. The reconnect logic only fired once the sync engine admitted it was disconnected, so nothing was retried while the pill said synced ^[7].

The cases that produce the window are ordinary phone behaviour: mobile data toggled off while the radio stays registered, a handoff to a cell that never completes, or a socket coming back from a long background period holding a file descriptor that points at nothing ^[4]. None of those closes the connection, and no FIN arrives ^[5]. A shorter keepalive would catch them sooner and burn battery reconnecting every time somebody walks into a lift ^[6].

Two weeks earlier the same developer had fixed a real complaint. Bringing the app to the foreground briefly drops and re-establishes the socket, so the pill flashed offline on every app switch ^[8]. The fix holds the current state and admits offline only if the socket is still down after a grace window, with a reconnect inside the window cancelling the pending flip, while connections still reflect immediately ^[8]. The debounce fixes the flicker, and it puts a deliberate delay on top of a signal that was already slow, so the worst case before the pill tells the truth is the grace window plus the heartbeat timeout ^[1]. The post does not say how long the grace window is.

The second signal is the operating system. expo-network exposes isConnected and isInternetReachable, and on the transports that populate them they flip well before a heartbeat gives up ^[11]. Both are typed boolean | null, and some transports never populate them at all ^[12]. The comment above the helper reads "// Only an EXPLICIT false means the OS is sure there is no internet." ^[19] So osOffline returns true only when osReachable === false or osConnected === false ^[13], and resolveSyncPill checks that first: the OS wins, then a false psConnected means offline, then psFlowing decides between syncing and synced ^[14].

The same disagreement drives the reconnect. needsForcedReconnect fires only when PowerSync believes its socket is up and the OS says there is no internet ^[15]. When PowerSync already admits it is disconnected, ordinary retry handles the case and a forced bounce would fight the backoff ^[16]. The bounce is rate-limited, and ten seconds between forced bounces was enough, which caps a flapping link at six forced reconnects a minute ^[17][2]. Clearing the local database to fix a connection is tempting and wrong, according to the post ^[18].

For any of this to transfer, the transports you actually ship on have to populate those two fields. Where they return null the resolver falls back to psConnected, and you are back to the heartbeat plus the debounce ^[13][14]. Treating null as false goes the other way and shows offline forever on hardware the developer does not own ^[12]. In an offline-first app I would take the extra input, because the failure it removes is a green pill reading synced on both phones while the item sits unsent ^[1].