That should be fine. The only guarantee you have with sequence counters is that they are increasing for events that have occurred in a happens-before relationship.
So to confirm, counters can increment by 2? Or is it more like there was events that are not captured in the history classes that incremented the counter?
Also: it’s a counter always within the history class and the process instance ID?
Yes, that is what you should always assume when working with counters.
The implementation reason for counters is increasing here is probably that other history events have received the intermittent numbers. These events have either been written to other tables or not at all (due to history level).
Not necessarily. For example two historic activity instances of the same process instance can have the same counter value. What you can rely on is the following:
When you have two history entries of the same process instance
And they have occurred in strict sequence with respect to sequence flow, i.e. it is not possible they could have occurred in any other based on the BPMN.
Then they can be ordered by the counter according to their order of occurrence
Examples:
You can meaninfully compare two historic activity instances by counter when the two activities are connected by plain sequence flows
You cannot meaninfully compare two historic activity instances by counter when the two activities are on parallel branches emerging from the same parallel gateway.
You can meaningfully compare a historic variable instance to a historic activity instance in the same scenario as example 1. However, this is currently not exposed via an API.
Is sequence counters used for internal sorting by the rest API? If yes, how do you detect if it was something like parallel gateway vs plain sequence flows?