[Bug]: Incoming message produces inconsistent messagesChangesPublisher diff ordering (latest message ends up at index 1)

[Anolcera]

Actual behaviour

When receiving an incoming message in a channel, messagesChangesPublisher emits two changes:
1. .insert(newMessage, index: 0)
2. .update(previousLatestMessage, index: 0)

There is no subsequent correction (e.g., a move/update for the previous latest), so after applying the diff the newest message ends up at index 1 instead of 0.

This breaks list reconciliation code that relies on the publisher’s diffs to be self-consistent.
On the incoming message, the publisher emits:

1. .insert(newMessage, index: 0)
2. .update(previousLatestMessage, index: 0)
   No follow-up .move or corrected .update is emitted. Applying these in order yields the previous latest at index 0 (updated) and the new message shifted to index 1, which is incorrect for a descending (newest-first) list.

Expected behaviour

One of the following self-consistent sequences:

Option A (insert + move/update with correct target):

1. .insert(newMessage, index: 0)
2. .update(previousLatestMessage, index: 1) // or a no-op if content unchanged

Option B (insert only, stable previous index):

1. .insert(newMessage, index: 0)
   // previousLatestMessage remains at index 1 implicitly

Option C (move semantics):

1. .move(previousLatestMessage, from: 0, to: 1)
2. .insert(newMessage, index: 0)

Any of the above would leave the newest message at index 0 and the previous latest at index 1.

Steps to reproduce

1. Open a channel with at least one existing message (the “previous latest”).
2. Subscribe to messagesChangesPublisher and log every ListChange<ChatMessage>.
3. Send a new message from a different user (incoming relative to the observing client).
4. Observe the emitted changes.

Which packages are you using?

StreamChat

Which SDK version are you using?

4.91.0

Which iOS version is the issue reproducible?

4.66.0-4.91.0

Which iPhone Device is the issue reproducible?

iPhone 16, iPhone 11

Which Xcode version are you using?

Xcode 16.4

[nuno-vieira]

Hi @Anolcera,

If you are not using our UI Components, we recommend not using the ListChange. They are driven by CoreData changes, which we found sometimes can be unreliable; that is why in the next major version, we are going to deprecate them. We recommend using your own Diffing solution and applying it to the existing messages data, and with the new messages reported by the delegate or publisher.

Just to double-check, when you open the channel again, are the messages in the correct order?

Best,
Nuno

[Anolcera]

Hi @nuno-vieira
Yes, when I re-open the channel messages are in correct order. what's weird is that, whenever I send a message, same exact thing happens at first but then I receive Update changes on current messages, which then correctly re-orders them again. This next batch of Update changes are not happening on receiving messages.

I am not using the UI components, but what do you suggest, getting whole messages from controller? I wonder if it would hit performance

[nuno-vieira]

Yes, that is what we do, and performance is great. Nowadays, diffing algorithms are quite performant. On UIKit, we use DiffKit, and on SwiftUI, we rely on the default SwiftUI algorithm.