Retrying a failed process flow run

This page has been updated re. some new features which will be available in our next scheduled release. If you don't see an option that's shown here, please check back after this release.

Introduction

If a process flow run fails for any reason, it's displayed in run logs with a status of failed - for example:

You can retry the run from this page. Before doing so, please consider:

  • It's advisable to check your process flow setup (filters and de-dupe shapes) to ensure that running the flow again will not duplicate any runs that may have succeeded in the interim period.

  • If a process flow includes references to variables, be aware that any values for those variables may not be the same as they would have been if the failed flow had been successful.

  • When the retry option is used, the flow version that was set originally is run. If you want to run an updated version of the process flow, you can choose to edit the flow and initialise a run manually instead.

  • A process flow must be enabled for the retry option to work.

The steps

Step 1 Log into the Patchworks dashboard and access your run logs & queue.

Step 2 Click the ellipses icon to access additional options for the log entry, then select the retry flow run option - for example:

About retry timings

When the retry option is used for a failed process flow run, the flow run is dispatched immediately*, using the current time to calculate any relative date filters and settings defined in the flow - unlike scheduled process flow runs which are added to a queue.

*Retried runs are not added to a queue, which means they will are processed as soon as possible. Often, this will be immediately, but in busier times a retry job may be placed behind others.

To ensure that any time elapsed between the time a failed run was originally queued and the time it is retried, the current time for a retry always assumes the queued at time for the original run that failed.

Example

Suppose that a process flow is scheduled (via a trigger shape) to start at 13:00.

  • At 13:00, the run is initialised and added to a queue. The queued at time is set to 13:00.

  • At 13:03 the queued run is processed. Because the use queued time process flow setting is toggled ON, the queue delay of 3 minutes is accounted for in all relative date/time settings defined in the flow.

  • The run fails.

  • At 17:00, the run is retried (via the run logs page). The retry happens immediately however, the current time assumes the original queued at time of 13:00.

Last updated