fix(sessions): new-session conversation fetch races the server's create, surfaces as a scary error

[RonenMars]

What happened

Confirmed from production streamer logs (~/.threadbase/logs/stdout.log), not just a UI glance.

Every time a new session is started, the client immediately polls GET /api/conversations/<id>?msg_limit=80 for a conversation record the server hasn't created yet (created lazily, only after the first message round-trips). The first poll(s) legitimately 404, and the client surfaces a "Some requests failed / Messages hit a wall" modal on the very first 404 instead of treating "conversation not created yet" as an expected transient state during session startup.

Evidence from production logs

Three separate conversation ids, each showing the identical pattern — several 404s immediately followed by 200s for the exact same id, all within a few seconds, always self-resolving:

4bbfd274-c7b5-4a90-8ef6-c9813cb63ca8: 6× 404, then 5× 200
0fe29dd4-1b94-45dc-9cca-3432e691c276: 4× 404, then 5× 200
1b5057e1-225c-4e46-8ebb-53e62bda5160: 4× 404, then 3× 200

Sample log lines:

{"time":"2026-09-04T16:19:19.398Z",...,"path":"/api/conversations/4bbfd274-...","status":404,"ms":102,"ua":"Threadbase/215 CFNetwork/3860.700.1 Darwin/25.6.0",...}
{"time":"2026-09-04T16:19:19.455Z",...,"path":"/api/conversations/4bbfd274-...","status":404,"ms":54,...}
{"time":"2026-09-04T16:19:20.944Z",...,"path":"/api/conversations/4bbfd274-...","status":404,"ms":22,"ua":"okhttp/4.12.0",...}

Notably, both an iOS client (Threadbase/215 CFNetwork...) and an okhttp/4.12.0 client hit the exact same conversation id within the same few seconds — two devices/clients polling concurrently on the same freshly-created conversation.

Why this matters

Functionally nothing is broken — it always self-heals within a second or two. But the user sees a jarring error dialog on essentially every new session they start, every time, on real production usage (not a synthetic test). It's a false-alarm UX bug, not a data-loss or correctness bug.

Distinct from other known issues

Not the "server is busy, retrying shortly" 429-laundering pattern (separate finding from E2EE program device testing, same day) — this is a plain 404 from the conversation-not-yet-created race specifically, not a rate limit.

Suggested investigation starting points

• Find where the client fetches conversation history immediately after starting/opening a session, and check whether it treats a 404 on that specific endpoint as "not created yet, retry silently with backoff" versus a generic request failure that surfaces the error modal.
• A minimal fix: suppress/delay the error UI for the first N (or first few seconds of) 404s specifically on /api/conversations/<id> right after a session start, and only surface an error if it's still 404 after a reasonable grace period — the log shows it always resolves within ~1-12 seconds.

[RonenMars]

Cross-reference: mobile #959 (error-banner redesign, open) touches services/api-client.ts and services/query-client.ts — the likely area a fix here would also touch. From its description, #959 is about display/classification/retry UX for errors already surfaced, not about suppressing the premature 404 during this specific new-session/conversation-creation race — so it doesn't look like it fixes this issue as a side effect, but check its current state before starting work here to avoid touching the same files at cross purposes.

[RonenMars]

Correction from the user — this is much broader than a new-session-only race.

It happens frequently, not just when starting a brand-new session: backgrounding the app, opening a session, and navigating between screens all trigger this error. So the original framing ("client polls immediately on new session, before the conversation record exists") is too narrow — it's likely a more general pattern where returning to/opening any session re-fetches conversation/session details and can hit a transient 404 or failure, not exclusively the create-race.

Also worth noting: at least one observed instance did not self-heal — a production log check for one specific session id showed only 3 requests over 30 seconds, all 404, no subsequent 200 (unlike the originally-reported cases which always resolved within ~1-12s). So there may be two distinct failure modes bundled under one symptom: (a) a genuine, self-healing startup race (as originally documented), and (b) cases where the session/conversation record is truly gone or never created, and retrying won't help.

Whoever picks this up should re-scope: audit every call site that fetches /api/sessions/<id> or /api/conversations/<id> on foreground/navigate/session-open (not just session-start), and distinguish "transient, will resolve" from "genuinely gone" before deciding how to handle each.