Hi, thank you for the detailed report.
This seems to be really a bug related to the combination of DISTINCT items, unfiltered dispatching, and snapshot handling.
Moreover, it is subject to a race condition that depends on the way snapshot and updates are produced.
All these conditions, unfortunately, occur in your case.

In particular, if the Data Adapter sends a snapshot event but not an end-of-snapshot event, the snapshot is kept and not sent to the subscribers.
As you can see from your log, only when a second update as non-snapshot is sent, is the snapshot forwarded to the session and a synthetic end-of-snapshot event added.
The reason for this delay is that a "distinct snapshot length" is configured, which poses a maximum limit to the snapshot to be sent to clients.
Hence the Server, as long as it doesn't know the final length of the snapshot that will be sent by the Data Adapter, it also doesn't know if it will have to truncate the first part; therefore it cannot initiate the transfer of the snapshot to the client.
As a consequence, the three events (snapshot, end-of-snapshot, and update) are sent in short sequence to the session and may be received in a different order, as happens at 21:26:57,803.
Obviously, the session is supposed to restore the order, but here comes the bug.

We will fix the bug as soon as possible thanks to your notice; but, anyway, you should escape from the bug by removing any of the various conditions described above.
I suppose that some of these conditions are not really wanted, but only side-effects of using the StockListDemo Data Adapter to receive updates in DISTINCT mode rather than MERGE.
In particular, in a real scenario, we suggest always sending the end-of-snapshot event for DISTINCT items, as the observed delay in sending the snapshot is already something that you should avoid.