🔥 [🐛] message.new events occasionally not delivered while WS healthy; messages retrievable via channel.query

[normanwilde]

Issue

Description

Receiver occasionally misses one or more new messages in a watched channel; sender sees them immediately. The missing messages appear only after the channel screen is unmounted/remounted (or after an explicit REST query / refresh).

Evidence

During investigation we intercepted raw WebSocket frames (ws.onmessage) and confirmed that for the missing message IDs no message.new frame arrives at the client at all (while the connection remains open/healthy). The same messages are present on the server and returned by channel.query(..., "latest").

Impact

Users perceive delayed/out-of-order/missing messages, most visible in high-throughput channels (artist/community) but also reproducible in DMs.
Workaround: Periodic reconciliation via channel.query({ messages: { limit } }, "latest") (every ~5s while foregrounded) plus running it on connection.recovered and AppState foreground.

Ask

Is it expected that message.new is best-effort and can be dropped even when WS reports healthy?
Is there a recommended client-side “precise gap detection” / watermark / sequence number / resume mechanism for this scenario?
Is there a Stream-supported way to sync a single channel state when no reconnect is detected?

Steps to reproduce

Steps to reproduce the behavior:

This is intermittent but reproducible with repeated runs:

1. Create or pick a channel with 2 members (DM or group).
2. Open the same channel on two devices (simulators/physical devices).
3. Keep both devices foregrounded on the channel screen.
4. From device A, send a burst of messages quickly (e.g. 10–30 messages within a few seconds).
5. Observe on device B: occasionally, 1+ messages never appear (or appear only after a long delay) until the channel screen is closed/reopened.
6. Verify on the backend / via REST that the message exists:
7. await channel.query({ messages: { limit: 100 } }, "latest") returns the “missing” message IDs.
8. In our investigation build, we also verified that the missing messages do not show up in raw WS frames on device B (no message.new payload received) even though the WS remains connected/healthy.

Expected behavior

All message.new events for watched channels are delivered to connected clients in order (or, if not guaranteed, the SDK provides a reliable “gap detection / watermark” signal so clients can automatically recover without periodic polling).

Project Related Information

Customization

Click To Expand

We use the standard RN SDK components; no special customizations relevant to WS transport. (We do have app-level wrappers around channel initialization, but the symptom is that the missing message never arrives at the socket frame layer.)

Offline support

• I have enabled offline support.
• The feature I'm having does not occur when offline support is disabled. (stripe out if not applicable)

Environment

Click To Expand

package.json:

{
  "expo": "55.0.14",
  "react": "19.2.0",
  "react-native": "0.83.4",
  "getstream": "8.8.0",
  "stream-chat-expo": "8.13.7"
}

react-native info output:

N/A (can provide if needed)

• Platform that you're experiencing the issue on:
  • iOS
  • Android
  • iOS but have not tested behavior on Android
  • Android but have not tested behavior on iOS
  • Both
• stream-chat-react-native version you're using that has this issue:
  • e.g. 8.13.7
• Device/Emulator info:
  • I am using a physical device
  • OS version: e.g. Android 10
  • Device/Emulator: e.g. iPhone 17 Pro, Air

Additional context

Screenshots

Click To Expand

---

[isekovanic]

Hi @normanwilde !

No, this should definitely not be happening. However, we haven't been able to reproduce this at all at any point (nor am I aware of any other integrators complaining about this).

I understand it happens intermittently, however is there potentially anything else going on when this occurs ?

When you say you're using

 "getstream": "8.8.0",

in your specification, what is this referring to ?

Also, can you reproduce this on one of our sample apps as well ? In your case I presume the ExpoMessagingApp would be most suitable since you're using Expo.

And finally, when you're saying that you aren't receiving WS events - how exactly are you checking this ? Is it through client.on('message.new', () => { ... }) or are you using a proxy (i.e Proxyman or CharlesProxy) in order to sniff out WS traffic ?

[normanwilde]

Hi @isekovanic,

Thanks for the quick reply.

I understand it happens intermittently, however is there potentially anything else going on when this occurs

Not that I noticed or that I'm aware of, just sending messages quickly back and forth between 2 clients.

When you say you're using

"getstream": "8.8.0",

in your specification, what is this referring to ?

I copied GetStream related packages from our package.json, getstream refers to https://www.npmjs.com/package/getstream, probably not relevant.

Also, can you reproduce this on one of our sample apps as well

I'll try but I'd need some time

And finally, when you're saying that you aren't receiving WS events - how exactly are you checking this

At the SDK layer: channel.on('message.new', ...) / client.on('message.new', ...) does not fire for the missing message id.

At the transport layer: we instrumented the underlying WebSocket by patching GetStreamClient.chat.wsConnection.ws.onmessage and parsing incoming frames. For the missing message id, there is no message.new JSON frame delivered to the JS runtime at all (while adjacent messages do arrive). The missing message is immediately returned via REST channel.query(..., "latest").

I attached a trimmed reproduction video, note that we stayed on the screen after the video ends but the missing message never appeared.

gs3.mov

[isekovanic]

Interesting, so even at a lower level within the low-level client it's not receiving WS events. That's... Odd for sure. This looks to me like either:

• WS events are being sent and/or are throttled server-side
• The underlying isomorphic-ws library somehow mismanages this

As I'm not sure which one it is yet, I'll bring this up internally and let you know if there's an update !

In the meantime, if you do manage to reproduce it consistently please do let me know, I haven't been able to.

Would you be so kind as to share your app ID with me as well ?

[normanwilde]

@isekovanic
Thanks again for looking into this. I can't share the app ID publicly here, but I opened a support ticket with the request to pass you the app ID.