Working with your run queue

Introduction

When a process flow run is initialised automatically (via a trigger shape or a Patchworks API request), the run job is added to your queue.

Manual runs (initialised from the canvas actions bar) and manual retries are NOT added to your queue:

Initialise method	Queued?
Trigger shape - schedule	queued
Trigger shape - webhook	queued
Trigger shape - event connector	queued
Run process flow shape	queued
API request	queued
Manual (via canvas actions bar)	not queued
Retry (via run logs)	not queued

How it works

The time that run jobs remain in the queue depends on various factors which are summarised below:

Factor	Summary
Concurrent process flows allowance	Refers to the maximum number of process flows that can be run simultaneously - the greater your allowance, the faster your queued run jobs are processed. This allowance is determined by your Patchworks subscription.
Scheduled process flows allowance	Refers to the maximum number of process flow run jobs that can be queued at any given time. If this allowance is exceeded, any subsequent run jobs are held until a queue slot is released (i.e. until an existing item in your queue is picked to be run). This allowance is determined by your Patchworks subscription.
The 'add to queue' frequency	The frequency that run jobs are added to your queue. This is a general system setting across the Patchworks platform - it's currently set to 30 seconds.
The 'pick from queue' frequency	The frequency at which run jobs are picked from your queue and run. This is a general system setting across the Patchworks platform - it's currently set to 05 seconds but will be reduced incrementally (aiming for every 1 second) over the coming days.
Queue priority	When configuring a process flow, you can set a queue priority (highest, high, regular, low, lowest). If set, this priority will affect the sequence in which run jobs are picked from your queue.

Points to note:

• Every 05 seconds, the system checks if any process flows are running:

  • If NO, it checks the queue and picks more flows to run - the number of flows picked will be the maximum allowed to meet your concurrent process flows limit.

  • If YES, it checks if our concurrent process flows limit has been reached. If it has, no more flows are picked from the queue. If it has not, the queue is checked and more flows are picked to run. The number of flows picked will be the maximum allowed to meet our concurrent process flows limit.

• If a process flow is triggered manually, it bypasses the queue and is run as soon as possible. A manual run still consumes one flow from your concurrent process flows allowance - so while it's running, one less job can be picked from your queue.

• By default, run jobs are picked from the queue in the sequence they were added. However, if a queue priority has been set for a process flow, it takes precedence. For example, if your queue contains 6 run jobs with no queue priority and then a new job is added for a process flow with a queue priority set to high, this will be the next job to be picked (despite being the last to be added to the queue). Conversely, if a job is queued for a process flow with a queue priority set to lowest, this will be the last job to leave the queue.

Viewing your run queue

You can view all of your pending runs from the queue tab - entries are listed chronologically based on the time that the job was added to the queue:

At a glance, you can see:

• Process flow name (hyperlinked so you can quickly access the flow)

• Environment (only applicable if you use virtual environments)

• Trigger

• Queued at time

• Priority

From here you can:

• Filter the queue by environment

• Remove a specific run job

• Remove all run jobs for a selected process flow

• Clear all run jobs

As soon as a pending job starts running, the entry is removed from this table and moves to the active run logs section.

Whether or not a process flow is queued depends on how it is initialised - see Are all run jobs queued? for more information.

Filtering your queue by virtual environment

If you use virtual environments, it can be useful to filter your run queue for a specific environment. You can do this using the environments dropdown selector at the top of the page. For example:

Removing a specific run job

To remove a specific run job from your queue (so it doesn't run), click the associated 'bin' icon:

When prompted, confirm this action.

In the unlikely event that you delete a run job that has already left the queue (because the dashboard has not refreshed), you'll be advised of this when you attempt to confirm the delete action.

Removing all run jobs for a selected process flow

To remove all run jobs for a particular process flow (so none of them run):

1

Select a process flow

Select the required process flow from the dropdown list at the top of the page:

2

(Optional) Filter by virtual environment

If you use virtual environments, you can filter your queue by environment using the dropdown selector at the top of the page. For example:

Any environments associated with jobs that are currently in the queue will be available for selection.

3

Remove queued runs

Click the remove all for flow button:

4

Confirm this action

When prompted, confirm this action.

Clearing all run jobs

1

(Optional) Filter by virtual environment

If you use virtual environments, you can remove all runs for a specific environment, using the dropdown selector at the top of the page. For example:

Any environments associated with jobs that are currently in the queue will be available for selection.

2

Clear the queue

Click the clear queue button. For example:

3

Confirm this action

When prompted, confirm this action.

Related information

• Viewing logs

• Viewing logs (classic)

• Downloading run logs

• Retrying a failed process flow run

• Email notifications for failed process flow runs

• Virtual environments