There is no submission timeout for messages being sent to the aggregator, meaning that we spend time processing messages that are too old. See #212 for more details.
New Behavior
We introduce a timeout based on the Aggregator current time (Unix timestamp), rejecting messages that are too old. We also adjust the checkpoint time range logic to be (lastCheckpointTimestamp + 1) to (currentTime - TIMEOUT)
Breaking Changes
There is a risk of now dropping messages if the timeouts are too strict. We'll need to monitor this change once its deployed.
Observations
The initial implementation uses a 60 second timeout. We also introduce a Clock abstraction for ease of testing that could be used in other parts of the codebase. It's up to discussion if we want to introduce a third-party library with more features to cover this use case.
Current Behavior
There is no submission timeout for messages being sent to the aggregator, meaning that we spend time processing messages that are too old. See #212 for more details.
New Behavior
We introduce a timeout based on the Aggregator current time (Unix timestamp), rejecting messages that are too old. We also adjust the checkpoint time range logic to be
(lastCheckpointTimestamp + 1) to (currentTime - TIMEOUT)Breaking Changes
There is a risk of now dropping messages if the timeouts are too strict. We'll need to monitor this change once its deployed.
Observations
The initial implementation uses a 60 second timeout. We also introduce a
Clockabstraction for ease of testing that could be used in other parts of the codebase. It's up to discussion if we want to introduce a third-party library with more features to cover this use case.