When there are a lot of events streamed from a worker, it's possible to have two batches coming for the same timestamp (which is a timestamp of the event on the worker). This way the existing logic would mess up the order because index and the random number doesn't guarantee the order.
To fix this I've changed the format of the prefix for the event to include tro things:
Timestamp in nanoseconds of the injection time on the controller so two sequential batches will have guaranteed order unless they are processed within a nanosecond.
Made the index being fixed length with trailing zeros, so they are properly lexicographically sorted (000001, 000002, ...).
When there are a lot of events streamed from a worker, it's possible to have two batches coming for the same timestamp (which is a timestamp of the event on the worker). This way the existing logic would mess up the order because
indexand the random number doesn't guarantee the order.To fix this I've changed the format of the prefix for the event to include tro things:
indexbeing fixed length with trailing zeros, so they are properly lexicographically sorted (000001,000002, ...).Fixes #88