Debounce/de-duplicate metric measurements and triggers #290
Description
What went wrong?
I am pretty sure what's happening in my scenario is that multiple event logs may appear in the same block at the same time, where I am producing a metric on each event as it is handled. The runner triggers immediately following a metric being returned from a task, which then creates a new task, potentially "front-running" the next metric-producing task (from event log). If you are doing incremental/in-memory updates (say ERC20 balance changes) using values from the event logs, they could become "out-of-sync" of what the on-chain value might be (since the on-chain value is only equal to the incrementally cached one after all event logs in that block have been processed)
How can it be fixed?
If possible, Silverback should perform the following sequence for triggers:
- blocks (add a way to specify before/after events in block?)
- event logs (process all of them before continuing)
- metric triggers (de-duplicate them, if multiple measurements of the same metric occur, only use/record the last one)
while crons are "time-sensitive", they are also async to blocks (unless the block occurs exactly on a time boundry), so trigger them first if a conflict exists. also usually produces a metric so it needs to be before then. This may rarely create the same issue (if the cron trigger takes long enough), but is much less likely to cause an issue since it fits a different use case (e.g. it is async to blocks)