Skip to content

collect all jobs before starting execution #11

@malteish

Description

@malteish

currently, when starting the canister, it might catch up on jobs, resulting in reverts.
Example: we scan 100 blocks, and job a should be executed every 10 blocks. It was executed in blocks 10, 20, 30, 40, resulting in 4 logs that order new executions. The canister would currently try to execute the job 4 times because it does not check if the execution has taken place. Instead of starting a timer each time, it should keep a list like this:
job -> nextExecutionTime

When scanning the 4 logs, nextExecutionTime is updated 4 times without execution. Only when the current block is reached should we scan for which job to execute.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions