Blog Post

Azure Integration Services Blog
2 MIN READ

Recurrence trigger not fired at specified frequency

Manohar_Patel_Seshapur's avatar
Jan 11, 2021

There might be scenarios noticed where recurrence trigger did not fire at specified frequency. This blog tries to consolidate these recurrence behaviors.

 

Recurrence trigger:

In some scenarios the start times of recurrences might drift due to factors such as latency during storage calls. The options that can be made use of to make sure that your logic app doesn't miss a recurrence are documented here .

 

Connection-based trigger:

In addition to the factors explained above for recurrence trigger, recurrences for connection-based triggers like SFTP-SSH, Service Bus etc.  the recurrence schedule isn't the only driver that controls execution, and the time zone only determines the initial start time. Subsequent runs depend on the recurrence schedule, the last trigger execution, and other factors that might cause run times to drift or produce unexpected behavior. For more information, see Recurrence for connection-based triggers.

 

Recurrences for connection-based triggers might also drift due to long polling nature of the trigger. If suppose, SFTP-SSH recurrence trigger 'When a file is added or modified' fires as per schedule and finds a file, another trigger will run again after 15 seconds to check if there are any more files present. The subsequent next trigger execution time is calculated from the last trigger execution time plus Recurrence interval. Hence, whenever trigger is fired, the immediate 15 seconds trigger is getting executed and altering the subsequent trigger executions.

 

In the below example, we have a simple logic app where the recurrence trigger checks if a file is added or modified every 3 minutes.

 

 

Let's consider the below 3 trigger runs.

 

 

Here, the trigger fired at 6:52:14 PM and found a file.

 

 

And then the trigger executed another run in roughly 15 seconds to check for any other pending files.

 

The subsequent next trigger which you would assume to run at 6:55:14 PM as per schedule has actually run at 6:55:33 PM i.e. 3 minutes after the follow-up trigger run that ended at 6:52:33 PM.

 

 

This is by design, contrary to normal assumption. So, every time the trigger fires and finds a file, the next subsequent would drift by roughly 15 seconds and in the long run the trigger recurrence would drift by hours or days from the expected schedule.

 

If this a concern, you can workaround this behavior by using a the normal recurrence trigger instead of the SFTP-SSH recurrence trigger as shown in the below sample.

 

Updated Jan 11, 2021
Version 1.0
No CommentsBe the first to comment