It's easy to imagine a polling integration flow where execution takes longer than the scheduling interval (e.g. more than 3 minutes), so practically speaking previous and next flow executions would overlap. In this case, the overlapping scheduling attempt will be skipped, so that elastic.io will make sure only at most one instance of your integration flow is active at any given moment. You will be notified about that event so that:
- You will see a 'failed scheduling attempt' error in your run-log on your dashboard.
- If you are subscribed to error notifications of your flow, you'll get a notification e-mail.
Example of Scheduling conflict
Let us see an example how scheduling would work - imagine your integration flow takes 5 minutes to execute and it is scheduled to execute every 3 minutes. Here is what will happen:
- You started your flow at 10:00 am
- 10:03 am next scheduling attempt will be done, but as the flow is still active it will be ignored. Failed attempt will be reported (see above).
- 10:05 am your integration flow completed its execution
- 10:06 am next scheduling attempt will be done and successful, your flow will start.
- The process continues...
This example highlights the importance of a proper timing when the scheduler is used with a polling tasks. When timed incorrectly, like it is shown in the above example, every second scheduling attempt will fail.
Please Note: Skipped scheduling attempts will not be retried.