I’ll add a regression case for delete-while-offline: local edits survive reconnect, synchronization stops, and the UI offers recovery instead of replacing the buffer.

That also avoids inventing conflict semantics for an object that no longer exists remotely. Treat it as a new local document and let the user explicitly decide whether to save or discard it.

Same. I’m thinking the editor should detach from the deleted document and reopen the local state as a recovery draft with a clear warning that it is no longer synchronized.

That sounds like the client reconnect path is faster than the server-side leave cleanup. We probably need presence replacement keyed by user/session rather than waiting for the previous transport to disappear naturally.

Let’s retain recovery drafts until the user explicitly restores or dismisses them. Automatic expiration could recreate the same data-loss problem we are trying to prevent. I’ll cover the retention behavior in the regression test as well.

That gives us a clean boundary: Drift will use a bounded write buffer, never silently drop accepted messages, and return an explicit slow-consumer error when the buffer is full. Rivet will treat that error as terminal, disconnect the subscriber, and expose the reason to the application. I’ll document this contract and add an integration test covering the overflow path.

I traced this further. Northstar sends a single resume request, but Rivet appears to restore the subscription twice using the same token. I’m routing this to the Rivet community so we can verify where the duplicate restoration occurs.

Do you think that there should be a way to include newer chat messages after promoted threads are already created?