Timeouts¶
A range of timeouts have been implemented for workflow execution, each with a default value designed to maintain system stability and ensure reliable operation.
You can adjust the default timeout values according to business requirements by updating the relevant system setting parameters directly in the BPA_SYSTEM_SETTINGS_TAB database table. Please note that after modifying these values in the database, the middle-tier containers restart is required for the changes to take effect. All timeout values are set in seconds. For more details, see the Asynchronous Workflows.
Note: Adjusting timeout values should be done with care, as increasing them may lead to transaction timeouts and could negatively impact system performance.
Adjust them only when you understand the impact on stability and related system limits. Always ensure values remain compatible with other system limits (e.g., API Gateway Timeout).
| Timeout Type | Parameter Name | Default Value | Description |
|---|---|---|---|
| Execution Timeout | SINGLE_THREAD_EXECUTIONS_TIMEOUT | 300 seconds (5 minutes) | Maximum execution time for Cascade Workflows, whether triggered synchronously ('Before' or 'After') or asynchronously. If chained or asynchronous workflows exceed this duration, the execution will fail with an error. Tip: Ensure this value is less than the API Gateway Timeout. |
| Async Thread Delay | ASYNC_THREAD_DELAY_SECONDS | 15 seconds | The thread sleep duration, specified in seconds, is applied when there are no asynchronous jobs to process before attempting to retrieve the next batch. |
| Debug Timeout | DEBUG_TIMEOUT_DURATION | 480 seconds (8 minutes) | Maximum duration allowed when running workflows in debug mode (Inspect BPA). If debugging takes longer than this period, the process will time out, and you will receive an error message: "It took long time to inspect the Workflow. Please limit the amount of data and try again". Tip: Consider the gateway timeout when setting this value. Setting it too high value may impact system stability. For additional tips see the troubleshooting timeout limit section. |
| ML Request Timeout | ML_REQUEST_TIME_OUT_SECONDS | 60 seconds | Time the system waits for a response to ML requests made from IFS AI Tasks. If not completed in this period, the request times out. |
| Async Thread Lock Timeout | ASYNC_THREAD_LOCK_TIMEOUT | 10800 seconds (3 hours) | This configures how many minutes the Asynchronous job lock is held in case the executor has failed. Once the timeout is reached Asynchronous job locks are released for reprocessing by another executor. The Default value is 180 minutes. Note: This parameter will be deprecated. Use Pod Cutoff Delay Interval and Pod Heartbeat Interval instead (see the rows below). |
| Pod Heartbeat Interval | BPA_POD_HEARTBEAT_INTERVAL | 3600 seconds (1 hour) | Interval (in seconds) between pod heartbeat updates. The heartbeat runner uses this interval to refresh pod presence in the database so the system can track which pods are active and detect when a pod has expired. Adjust based on your deployment. Lower values increase Database load and higher values may delay pod expiry detection. For more information, see Heartbeat Runner. |
| Pod Cutoff Delay Interval | BPA_POD_CUTOFF_DELAY_INTERVAL | 600 seconds (10 minutes) | This is an additional buffer added to the Pod Heartbeat Interval when checking whether the other OData Provider instances are inactive. Modifying this value affects how long the runner waits before retrying a failed heartbeat. For more, see Heartbeat Runner. |