[isekovanic]

Ticket: https://linear.app/stream/issue/REACT-1311

CLA

• I have signed the Stream CLA (required).
• Code changes are tested

Description of the changes, What, Why and How?

A send can reach the server while its response never reaches the client. The usual cause is the client's 3000ms request timeout, which matches the backend's write timeout, so a slow request can time out on the client after the server has already saved the message. The client then marks the message failed, and every later attempt with the same ID gets "already exists". This was handled for v9 in #1907, which was closed in favour of fixing it in v10. This PR covers every path a send takes in v10.

Commit	Fix
7e82010b	A send or retry rejected with "already exists" resolves instead of rejecting
3f403ed0	A send whose server copy arrived before the request failed stays sent
9bf9ca86	A queued send replayed after reconnecting marks the message received on "already exists"
a7ce5c68	Test coverage for the replay

"Already exists" on send and retry

Commit: 7e82010b

MessageOperationStatePolicy.failure() already marked the message received on "already exists", but MessageOperations.run() rethrew the error anyway. So composer.send() returned 'failed' and reported "Send message request failed" for a message that had been sent, and retry() rejected, so a resend could never succeed.

failure() now returns whether the operation succeeded after all, and run() only rethrows when it didn't. That's the case only for "already exists" on a send or retry. An edit or a delete rejected with the same code is treated as a failure, as before. A successful send also clears its entry in the failed-send cache.

The other half of the ticket, the default update request ignoring a handler's options, was already fixed by #1949.

Server copy before the failure

Commit: 3f403ed0

When the server saves the message just before the client's timeout fires, its message.new can arrive first and the message shows as sent. The timeout then reached failure(), which marked the message failed without checking what was held, so a sent message flipped back to failed.

A send or retry now counts as successful when the held message is already received. Since the optimistic step sets it to sending, a received copy can only come from the server.

Replay from the offline queue

Commit: 9bf9ca86

With offline support, a send that times out is also queued. When the queue replays it after reconnecting and the server answers "already exists", executePendingTasks deleted the task but left the message failed, until a reload or a retry fixed it.

QueueableOperation gets an onReplayRejected hook next to onReplay, and executePendingTasks calls it before deciding whether to keep the task. The send-message operation uses it: on "already exists", a held message that is still failed is upserted into client.messageStore as received, which updates every list holding it (the channel and, for a reply, its thread), and is written to the offline DB under the task's channel. A message that isn't failed any more, or isn't loaded, is left alone. The hook runs only for replays, so first attempts keep going through the message-operations layer.

Testing

Commit: a7ce5c68

• Send and retry: "already exists" resolves and leaves the message received; an edit rejected with the same code still rejects and is marked failed; the composer returns 'sent' with no notification.
• Server copy first: a request that stores a received copy and then times out resolves and keeps the server's copy, and the composer returns 'sent'.
• Replay: a failed message and a failed thread reply end up received; another rejection leaves the message failed; a message that's already settled or isn't loaded is left alone; the offline DB gets the received message under the task's channel; executePendingTasks hands a rejected replay to the hook.
• Each new test fails without its fix.
• yarn test, yarn run types, eslint and prettier pass.

Changelog

• Fix a send the server already has being reported as failed, on send, retry and offline replay.
• Fix a sent message flipping back to failed when the request times out after its message.new arrived.

[MartinCupela]

Reviewed at a7ce5c689 against REACT-1311; both parts of the ticket are covered. yarn test (4,895) and the type check pass locally. One bug: a retry that gets "already exists" ends up received but keeps the error from the failed attempt.

• The "already exists" branch of MessageOperationStatePolicy.failure() builds the received copy from localMessage, the message the caller passed in. On a retry that's the failed message, which still has error. The optimistic step clears error on the stored copy ({ ...localMessage, error: undefined, status: 'sending' }), and this branch puts it back.
• stream-chat-react treats a message with error as failed in its action menu (useBaseMessageActionSetFilter.ts:98). It keeps only resend, edit and delete, each under extra conditions, so a sent message can end up with no actions until it's replaced or the page reloads.
• Example: a send times out after the server saved it, and the user taps Resend. The server answers "already exists" and retry() resolves. The message shows as sent, but its menu still behaves as if it failed.
• Fix: { ...localMessage, error: undefined, status: 'received' }, as the replay hook already does. Adding expect(store.get('m1')?.error).toBeUndefined() to "resolves a retry that the server rejects with 'already exists'" fails today ("expected {} to be undefined").

[isekovanic]

@MartinCupela fixed here

[MartinCupela]

755dcaf6e fixes the stale error on an "already exists" retry. The new assertion fails without the fix and passes with it, and all 4,895 tests and the type check pass.

[stream-ci-bot]

🎉 This PR is included in version 10.0.0-rc.31 🎉

The release is available on:

• GitHub release
• npm package (@rc dist-tag)

Your semantic-release bot 📦🚀

[stream-ci-bot]

🎉 This PR is included in version 10.0.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀