Lucas RayanandClaude Opus 5
93d21b4752
F4 lists real-time updates and the interface had none: an open inbox only changed when the user reloaded it. Events come from the transactional outbox rather than from an in-process callback, which is what the outbox is for (PLAN.md section 9.4): the row is written in the same transaction as the message, so an event can never describe a delivery that rolled back, and a crash between commit and publish loses nothing because the row is still there on restart. The relay claims rows with SKIP LOCKED so a second instance can help without publishing anything twice. The hub fans events out per mailbox, keyed by the mailbox the session resolved to, so one account's arrivals are never visible to another even though they share the process. A subscriber that stops reading is dropped rather than allowed to stall the relay; it reconciles on reconnect. The client reconnects with capped exponential backoff and treats every successful connect as a resync, refetching the folder. Without that, a socket that dropped for a minute would leave the list quietly stale, which is worse than having no real-time updates at all. The upgrade goes through a Next rewrite, not the API route handler: a route handler sees a finished request and cannot upgrade a connection. Verified against the running stack - the handshake returns 101 through the Next server, and a message delivered on port 25 arrives as a frame on an already-open socket without the page asking for it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>