{
  "id": 15108977,
  "title": "Realtime Publish Alone Cannot Deliver Chat Room Notifications After Disconnects",
  "url": "https://urgent.news/2026/10/17/realtime-publish-alone-cannot-deliver-chat-room-notifications-after",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-17T03:41:02.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/elvrythn486209/realtime-publish-alone-cannot-deliver-chat-room-notifications-after-disconnects-1mcg"
  },
  "original_language": "en",
  "account": "Realtime publish alone is insufficient for delivering chat room notifications to clients that disconnect. Notifications sent during a user's absence will not be seen when they return. To ensure notifications are delivered even after a client disconnects, persist notifications in an inbox before publishing. Assign a monotonically increasing cursor within a clearly defined scope and let clients acknowledge what they have processed. When clients reconnect, backfill all notifications after their acknowledged cursor. The realtime path provides fast delivery, but the inbox enables reliable recovery. In developer tool chat rooms, a browser can disconnect between a build mention and an engineer returning to the tab. A transport can transmit data while clients are connected, but it cannot guarantee that an absent client will later see an application event. Realtime publish success is not an accurate indicator of user-visible notification outcomes. Instead, measure the progression of notifications through creation, acknowledgement, and recovery. The inbox pattern involves persisting notifications, signaling delivery, acknowledging receipt, and enabling recovery upon reconnection. Record four timestamps for each notification: inbox commit, publish attempt, client receipt, and acknowledgement. Also note the reconnect cursor provided by the client and the highest cursor returned during backfill. These timestamps help trace the notification's journey and identify discrepancies between committed and acknowledged cursors. When designing the notification system, choose a durable boundary for records. In a transaction, insert the domain change and the notification inbox record, or derive both from the same committed event. Publish only after the commit is successful. If publishing fails, the record remains available for later backfill. If publishing succeeds but the client disconnects before processing, the record remains available after the last acknowledged cursor. Implement at-least-once redelivery with deduplication based on notification ID. Exactly-once semantics can obscure the boundary between records and client connection states. Provide a stable ordered page to clients by using per-user or per-room cursors, or a global cursor for simpler storage at the cost of potentially exposing unrelated traffic patterns. Pick the cursor scope based on the ordering promise and capacity plan accordingly. The provided Go interface defines the inbox boundary, including notification structure and store operations for appending, querying by cursor range, and acknowledging notifications. The acknowledgement function should advance monotonically, preventing backward movement upon retries and ensuring a deterministic order for fetching pages. When reconnecting, clients authenticate, submit their last acknowledged cursor, request a bounded page, apply received records idempotently, acknowledge the highest contiguous cursor, and repeat until caught up with live delivery. If live events arrive during backfill, buffer them by cursor or establish a server watermark before switching modes to avoid gaps or timeline reordering. Limit backfill responses to prevent overwhelming clients, especially when peak notification creation rates exceed their offline window capacity.",
  "summary": "Realtime publish alone cannot reliably deliver notifications to a disconnected chat-room client. That is why the page says notification delivery has fallen below its SLO even though the on-call sees healthy publish latency, connected subscribers, and no obvious transport errors: users who closed a laptop during a deployment never see the mentions sent while they were away. TL;DR: a realtime…",
  "key_points": [
    "Realtime publish alone insufficient for post-disconnect chat notifications.",
    "Persist notifications in inbox before publishing to ensure delivery.",
    "Implement at-least-once redelivery with deduplication for reliable recovery."
  ],
  "editors_take": "Relying solely on real-time publishing creates gaps in user communication, requiring a durable inbox pattern to ensure that disconnected clients can reliably recover and process missed notifications upon reconnection.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}