Sent is not delivered until the other side can read it.
The UI says the message was sent, but the other person never receives it.
The problem
The UI says the message was sent, but the other person never receives it.
When this breaks after deploy, the cost shows up as lost revenue, locked-out users, support load, or silent data mistakes — not as a red unit test in CI.
What can break
- send succeeds locally but peer never renders
- duplicate messages
- stale thread after reconnect
- typing indicator stuck
The critical flow
- 1connect (fixture session)
- 2send
- 3receive/render
- 4delivery indicator
- 5typing indicator (fixture)
What Endia checks
Session connects
Both fixture panes show connected/ready state
Send message
Composer send places the message in the sender thread
Peer receives
Peer pane renders the same message body
Delivery render
Delivery/read fixture indicator updates after peer render
Typing indicator
Typing state appears on the peer while composing
What evidence you get
Screenshots of both panes, step trace, and the release check result.
How it fits the Vercel preview gate
Catch messaging UI regressions on previews before support tickets pile up.
Try the protected flow (controlled fixture)
Neutral demonstration fixture — not a customer app, not live production data. Walk the flow Endia would record and replay on a Vercel preview.
Session: connected · dual-pane fixture
You
Peer
Browser-level send/receive/render only — not a WebSocket protocol claim.
Known limitations
- Verifies browser-level send/receive/render in a controlled dual-pane fixture.
- Does not claim WebSocket protocol coverage or multi-server fan-out.
- Presence beyond typing is not asserted.
Protect a flow like this
Sign in to record your critical journey and run it on every Vercel preview.