fix(messaging): stop discarding the user's message when a send fails

[TortoiseWolfe]

The last deterministic E2E failure (offline-queue.spec.ts, shard msg-3/4, 100% of runs). It is a real product bug, not a test bug.

A message that fails to send because of a network-layer fault — while the browser still reports navigator.onLine === true — is silently thrown away.

From the failing CI trace (run 30845792628):

[sendMessage] INSERT failed {error: Failed to send message: TypeError: Failed to fetch}

Zero offline-queue-updated events. The failure screenshot shows the thread reading "No messages yet. Send the first one!" with the composer cleared. The user's typed text is gone — not queued, not recoverable, not even an error banner.

Root cause: two sibling predicates disagreed

	matched a thrown TypeError	matched an error object
isTransientFetchError	✅	✅
isNetworkError	✅	❌

supabase-js never throws on a failed fetch — postgrest-js catches it and returns { error: { message: "TypeError: Failed to fetch", … }, status: 0 }.

So the INSERT gets an error object. isTransientFetchError recognises it and enters the RLS-retry loop; the retry aborts too, and since that error has no .code and isn't an RLS error, the send throws ConnectionError ~2s in. isNetworkError then sees a ConnectionError — not a TypeError — with onLine still true, returns false, and the offline queue, which exists for exactly this case, is never reached. messages/page.tsx:458-460 then deletes the optimistic bubble.

isNetworkError now delegates to isTransientFetchError, so the two cannot drift apart again.

Also fixes a pre-existing browser gap

Both predicates only looked for 'fetch'/'network'/'failed to fetch'. The engines word it differently:

Chromium  "TypeError: Failed to fetch"
Firefox   "TypeError: NetworkError when attempting to fetch resource."
WebKit    "TypeError: Load failed"        ← matched NEITHER

On WebKit isTransientFetchError already returned false today, skipping the retry path entirely. Both branches now share one looksLikeFetchFailure covering all three. Without this the webkit shard would have stayed red.

Test corrections in the same file

• Renamed from "should show failed status after max retries". There is no failed-status UI — MessageBubble has no status handling, DecryptedMessage has no status field. What it actually asserts is that the message survives.
• expect(interceptCount).toBeGreaterThanOrEqual(1) was vacuous — the route pattern also catches the GET from the 10s polling refetch, so the counter climbed even when no send occurred. Counts POSTs now.
• The 35s "wait for retries to exhaust" was fiction. Retries never exhaust on this path; the outcome is settled ~2s after the click. Reduced to 10s, removing ~25s of dead time per run per browser.

Verification

Diagnosis was adversarially reviewed by three independent agents across control-flow, supabase-client and UI/test-validity lenses. All three failed to refute it. Their corrections are incorporated: the throw site is the first inner retry (not retry exhaustion), the WebKit wording gap, and the vacuous assertion.

One reviewer confirmed the chain against the actual CI trace rather than statically — including the 2000 ms gap matching the retry loop's Math.min(2000 * 2^0, 16000) backoff.

Local: type-check clean, lint 0 errors, 388 test files pass.

Follow-up worth doing

postgrest-js sets status: 0 on every fetch-layer failure in every engine — a stronger signal than matching message text. Using it means capturing the status at the INSERT site rather than re-deriving intent from a stringified wrapper two frames later. Not done here because it changes the send path's shape; the string predicate is now centralised in one function so a fourth engine wording is a one-line change.

Refs #66, #76.

🤖 Generated with Claude Code