Events with same timestamp being projected/exported in wrong order

[maggo]

Hi I have a case where I'm importing a bunch of events with the same timestamps, many also acting on the same aggregateId.

This works fine when importing, and looking at the threadCounter they're also saved correctly, but when I do an export or reset my read model they're in the wrong order. Maybe there's some weird sorting error?

Any way to force an order when events have the same timestamp?

Edit:

I'm using the sqlite adapter for development and after some reading through code I found that get-latest-event of mysql has a secondary sort for aggregateVersion which is missing in the sqlite version could it be that other sql queries are also missing this?

---

More info, I'm calling eventStore.incrementalImport with an array of events, many which have the same timestamp. The original order they're saved to the DB seems to be fine when I look at it with a client, but whenever the events are read from the database (eg for projection or export) they go out of order.

Also for some reason the last event has a lower threadCounter value than the other events, which could explain the weird sorting?

Edit edit 😅 :

Just found that load-events-by-timestamp does sort by threadCounter ORDER BY "timestamp" ASC, "threadCounter" ASC, "threadId" ASC
also realized that in my database the threadCounter counts down instead of up, with some numbers missing here and there. Is this expected or could it be fixed somehow?

Correct:

threadId	threadCounter	timestamp	aggregateId	aggregateVersion
72	149	1626110770000	6457	1
73	149	1626110770000	6457	2
10	186	1626132179642	6457	3
11	186	1626132179642	6457	4
12	186	1626132179642	6457	5
13	185	1626132179642	6457	6

How it's being projected/exported:

threadId	threadCounter	timestamp	aggregateId	aggregateVersion
72	149	1626110770000	6457	1
73	149	1626110770000	6457	2
13	185	1626132179642	6457	6
10	186	1626132179642	6457	3
11	186	1626132179642	6457	4
12	186	1626132179642	6457	5

[FreeSlave]

Hello. Thanks for reporting the issue.
The current design did not cover the case that events belonging to the same aggregateId might have equivalent timestamps. We'll look into the ways to solve this problem in the next releases.

[MrCheater]

We reproduced the issue and fixed it in #1970 for sqlite-adapter. You can try it out on version 0.31.5

[MrCheater]

I’m closing this issue because it has been inactive for a month. This probably means that it is not reproducible or it has been fixed in a newer version.

Please reopen if you still encounter this issue with the latest stable version. You can also contribute directly by providing a patch.

Thank you!