Description
When we store event traces, we have different sorting criteria. For Camunda events, we use orderCounters or where missing, use timestamps. For external events, we use timestamps. In cases where timestamps are the same, we look through our existing sequence counts to resolve the more likely sequence. This covers most cases sufficiently, but also leaves open the possibility to introducing and reinforcing bias in our sequence counts for a given source. For example, if the first 100 traces had identical timestamps for events A and B, before we started receiving traces where the timestamps are different, the lookup will incorrectly sequence any future identically timestamped events.
To cover this, we should stop incrementing the sequence counts where two events are the same. In some scenarios, there might be events before or after the identical timestamps, in which case we can count the sequence from the nearest neighbour. If that isn't the case, we would have to accept that our counts might be incorrect at the trade-off of accuracy.
The context for this is quite complex so feel free to go over with joshua.windels or sebastian.bathke.
ATs:
- traced events that can't be ordered accurately should not be counted towards event sequence counts
mgm-controller-panel
This is the controller panel for Smart Panels app
Attachments
Issue Links
- is related to
-
OPT-3376 Utilize Camunda Activity Sequence counters for ordering camunda activity events
-
- Done
-