messaging: no live updates — recipient must reload to see new messages #182

New issue

Open

opened 2026-04-29 13:23:15 +00:00 by rawdaGastan · 0 comments

rawdaGastan commented

2026-04-29 13:23:15 +00:00

Member

Problem

The messaging archipelago is pull-only — there is no SSE / WebSocket / poll loop. After mount the conversation list and active-chat messages are fetched once; they are never refetched on their own. A user who sends a message can see it (optimistic update from the closed #45 patch), but the recipient sees nothing until they reload the page or navigate away and back.

Repro

Open the same DM in two browser tabs (currently both see the same data thanks to hero_osis #40 — separate contexts will work the same way once that lands).
Send from tab A.
Tab B: nothing happens. Refresh → message appears.

Why this is worse than it sounds

Combined with hero_archipelagos #62, on the next reload tab B sees the new message and its own historical messages all rendered as bubble-other. Effectively no one can tell who sent what without auth.

Suggested fix

Short-term: poll conversation.list + conversation.list_messages(active_sid) every N seconds while the island is focused.

Medium-term: add an SSE/WS subscription on the hero_osis_communication socket and stream chatmessage.new / conversation.updated events to subscribed clients.

Found via QA session 2026-04-29 (qa/messaging_2026-04-29/FINDINGS.md).

## Problem The messaging archipelago is pull-only — there is no SSE / WebSocket / poll loop. After mount the conversation list and active-chat messages are fetched once; they are never refetched on their own. A user who sends a message can see it (optimistic update from the closed #45 patch), but the *recipient* sees nothing until they reload the page or navigate away and back. Grep for `subscribe|interval|poll|watch|stream|sse` under `archipelagos/messaging/src/` returns nothing. ## Repro 1. Open the same DM in two browser tabs (currently both see the same data thanks to hero_osis #40 — separate contexts will work the same way once that lands). 2. Send from tab A. 3. Tab B: nothing happens. Refresh → message appears. ## Why this is worse than it sounds Combined with hero_archipelagos #62, on the next reload tab B sees the new message *and* its own historical messages all rendered as `bubble-other`. Effectively no one can tell who sent what without auth. ## Suggested fix Short-term: poll `conversation.list` + `conversation.list_messages(active_sid)` every N seconds while the island is focused. Medium-term: add an SSE/WS subscription on the `hero_osis_communication` socket and stream `chatmessage.new` / `conversation.updated` events to subscribed clients. Found via QA session 2026-04-29 (`qa/messaging_2026-04-29/FINDINGS.md`).