Parallel Execution Settings

Configure concurrent workflow processing for Lifecycle Management

Endpoint

GET /api/private/lifecycle_management/parallel_execution_settings
PUT /api/private/lifecycle_management/parallel_execution_settings

Description

Configure how Lifecycle Management processes workflows concurrently. These settings control the maximum number of simultaneous jobs, workflows, and access requests, as well as how paused tasks affect the running queue.

Use these endpoints to:

  • View current parallel execution configuration

  • Adjust concurrency limits for workflow processing

  • Configure max_paused_slots to prevent safety limit bypass from paused tasks

Get parallel execution settings

Retrieve the current parallel execution configuration.

curl -X GET "https://your-tenant.vezacloud.com/api/private/lifecycle_management/parallel_execution_settings" \
  -H "Authorization: Bearer YOUR_API_TOKEN"

Use the :details suffix to get additional information about the current settings:

curl -X GET "https://your-tenant.vezacloud.com/api/private/lifecycle_management/parallel_execution_settings:details" \
  -H "Authorization: Bearer YOUR_API_TOKEN"

Update parallel execution settings

Modify the parallel execution configuration.

Request body

Field
Type
Default
Description

jobs

integer

1

Maximum number of concurrent policy jobs that can run simultaneously

workflows

integer

1

Maximum number of concurrent workflows per job

access_requests

integer

1

Maximum number of concurrent access request workflows

max_paused_slots

integer

0

Maximum number of paused tasks that can free up running slots

Understanding max_paused_slots

The max_paused_slots setting controls how paused tasks (waiting for approval, delay actions, etc.) affect the running queue.

When parallel workflow processing is enabled, a paused task frees up a slot in the running queue, allowing another task to start. However, safety limit checks only occur when tasks startโ€”not when they resume from pause. This creates a vulnerability where the safety limit can be significantly exceeded:

  1. Task starts and passes the safety limit check

  2. Task pauses (waiting for approval, delay, etc.)

  3. Pausing frees a slot, allowing a new task to start

  4. Steps 1-3 repeat, creating many paused tasks

  5. When paused tasks resume, they run without re-checking the safety limit

The max_paused_slots setting mitigates this:

  • First N paused tasks: Decrement the running count (freeing slots for new tasks)

  • Additional paused tasks: Remain counted as "running" (no new tasks can start)

This limits how many paused tasks can bypass the safety limit while still allowing some parallelism for workflows with pause actions.

Configuration recommendations

Value
Behavior

0 (default)

Paused tasks never free slots. Safest configuration but lowest throughput for workflows with pauses

10-50

Moderate parallelism. Good balance for most environments

100+

High throughput for environments with many approval workflows. Higher risk of safety limit overshoot

Response

Last updated

Was this helpful?