Durable realtime events

Scrydon records operational organization events in a durable, organization-scoped log before they reach realtime clients. A domain change and its outgoing event are committed together in the writer database. A relay publishes the committed event, and the platform stores an ordered ledger with an independent checkpoint for each supported consumer.

This provides at-least-once delivery: a consumer may see the same event again after a retry, but it does not silently lose a committed event. Scrydon consumers use the event ID for idempotency and acknowledge progress only after their destination work succeeds.

Realtime organization events are thin invalidation signals. They tell a client that governed data changed; they do not contain a replacement copy of the governed record. The client re-reads through the normal authorization and data-policy path.

Browser reconnects

The org-events client negotiates the durable protocol with the realtime server. New servers return an opaque cursor key scoped to the signed-in user and active organization. The client saves the last dispatched offset, requests missed signals after reconnect, orders live and catch-up envelopes, removes duplicates, and advances the cursor after the application handler runs.

If retained history no longer covers the saved cursor, the client clears it, invokes the application's governed full-resync callback, and resumes from the latest retained position. During a mixed-version deployment, a bounded negotiation timeout attaches the legacy live-only socket listeners; a successful durable capability response suppresses that fallback.

Applications using subscribeOrgEvents receive the same event-name handlers as before. Durable envelopes and cursor storage are handled by the shared SDK kernel; application code should continue treating every signal as a reason to refresh governed data.