From 2459c7f36a0910136757d6b684d200400c5221c8 Mon Sep 17 00:00:00 2001 From: Ken'ichiro Oyama Date: Tue, 28 Apr 2026 00:00:24 +0900 Subject: [PATCH 1/3] docs: add workflow concurrency limits to platform limits page --- docs/reference/platform/platform-limits.md | 29 +++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/docs/reference/platform/platform-limits.md b/docs/reference/platform/platform-limits.md index 398f557..df79ad1 100644 --- a/docs/reference/platform/platform-limits.md +++ b/docs/reference/platform/platform-limits.md @@ -8,9 +8,11 @@ Platform limits are enforced across different services in the Tailor Platform to ## Service Limits -| Service | Limit Type | Limit Value | Description | Impact | -| -------------------- | ---------- | ----------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------- | -| Recursive Call Limit | Call Depth | 10 levels | Max depth for nested platform-to-platform requests (pipelines, functions, etc.) | Request rejected with BadRequest error if depth exceeds 10 levels | +| Service | Limit Type | Limit Value | Description | Impact | +| -------------------- | ------------------------------- | ------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | +| Recursive Call Limit | Call Depth | 10 levels | Max depth for nested platform-to-platform requests (pipelines, functions, etc.) | Request rejected with BadRequest error if depth exceeds 10 levels | +| Workflow | Workspace Concurrent Executions | 50 executions | Max concurrent workflow executions per workspace | Pending executions remain in PENDING status until running executions drop below the cap | +| Workflow | Per-Workflow Concurrent Executions | 20 executions | Max concurrent executions of a single workflow | Pending executions remain in PENDING status until running executions drop below the cap | ## Recursive Call Detection @@ -34,6 +36,25 @@ This limit prevents issues in scenarios such as: - Executor workflows that create cascading service calls - Event loops where service operations trigger events that cause the same operations to execute again +## Workflow Concurrency Limits + +The Tailor Platform enforces concurrency limits on workflow executions at the scheduler level to prevent resource exhaustion and ensure fair scheduling across workspaces. + +### How It Works + +Two independent limits control the number of concurrent workflow executions: + +- **Workspace-wide limit (50)**: Caps the total number of concurrently running workflow executions within a single workspace. This prevents any one workspace from monopolizing platform resources. +- **Per-workflow limit (20)**: Caps the number of concurrently running executions of the same workflow definition. This prevents a single high-volume workflow from starving other workflows in the workspace. + +When either limit is reached, new executions are not rejected. Instead, they remain in **PENDING** status and are re-evaluated on the next scheduler polling tick. Once running executions complete and slots become available, pending executions are transitioned to RUNNING automatically. + +### Behavior + +- Both limits are enforced independently. An execution must satisfy both limits to start running. +- If the workspace-wide limit is reached, no new executions start in that workspace regardless of per-workflow counts. +- If the per-workflow limit is reached for a specific workflow, other workflows in the same workspace can still start new executions (as long as the workspace-wide limit is not reached). + ## Best Practices When working with services that have call depth limits, consider the following best practices: @@ -45,3 +66,5 @@ When working with services that have call depth limits, consider the following b 1. **Design for limits**: Anticipate depth limits and handle them gracefully in your application logic. 1. **Use alternative patterns**: Consider using event-driven architectures, queuing systems, or batch processing for complex workflows that might exceed depth limits. + +1. **Design for workflow concurrency**: If your application triggers many workflow executions simultaneously, be aware that excess executions will queue as PENDING. Design your application to handle this gracefully rather than assuming immediate execution. From bbbded4964ce4fa5cd943442a6ba6c7b639d369b Mon Sep 17 00:00:00 2001 From: Ken'ichiro Oyama Date: Tue, 28 Apr 2026 00:12:56 +0900 Subject: [PATCH 2/3] docs: broaden best practices intro to cover all platform limits --- docs/reference/platform/platform-limits.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/reference/platform/platform-limits.md b/docs/reference/platform/platform-limits.md index df79ad1..a28e1cf 100644 --- a/docs/reference/platform/platform-limits.md +++ b/docs/reference/platform/platform-limits.md @@ -57,7 +57,7 @@ When either limit is reached, new executions are not rejected. Instead, they rem ## Best Practices -When working with services that have call depth limits, consider the following best practices: +When working within platform limits, consider the following best practices: 1. **Avoid deep service nesting**: Design workflows to minimize the depth of service-to-service calls. Consider flattening complex nested operations or using alternative patterns like event-driven architectures with proper safeguards. From d46655e6fcd005016d9b74697edc83a8a330c310 Mon Sep 17 00:00:00 2001 From: Ken'ichiro Oyama Date: Tue, 28 Apr 2026 00:17:38 +0900 Subject: [PATCH 3/3] docs: use consistent inline code formatting for status values --- docs/reference/platform/platform-limits.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/reference/platform/platform-limits.md b/docs/reference/platform/platform-limits.md index a28e1cf..0c9c28f 100644 --- a/docs/reference/platform/platform-limits.md +++ b/docs/reference/platform/platform-limits.md @@ -11,8 +11,8 @@ Platform limits are enforced across different services in the Tailor Platform to | Service | Limit Type | Limit Value | Description | Impact | | -------------------- | ------------------------------- | ------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | Recursive Call Limit | Call Depth | 10 levels | Max depth for nested platform-to-platform requests (pipelines, functions, etc.) | Request rejected with BadRequest error if depth exceeds 10 levels | -| Workflow | Workspace Concurrent Executions | 50 executions | Max concurrent workflow executions per workspace | Pending executions remain in PENDING status until running executions drop below the cap | -| Workflow | Per-Workflow Concurrent Executions | 20 executions | Max concurrent executions of a single workflow | Pending executions remain in PENDING status until running executions drop below the cap | +| Workflow | Workspace Concurrent Executions | 50 executions | Max concurrent workflow executions per workspace | Pending executions remain in `PENDING` status until running executions drop below the cap | +| Workflow | Per-Workflow Concurrent Executions | 20 executions | Max concurrent executions of a single workflow | Pending executions remain in `PENDING` status until running executions drop below the cap | ## Recursive Call Detection @@ -47,7 +47,7 @@ Two independent limits control the number of concurrent workflow executions: - **Workspace-wide limit (50)**: Caps the total number of concurrently running workflow executions within a single workspace. This prevents any one workspace from monopolizing platform resources. - **Per-workflow limit (20)**: Caps the number of concurrently running executions of the same workflow definition. This prevents a single high-volume workflow from starving other workflows in the workspace. -When either limit is reached, new executions are not rejected. Instead, they remain in **PENDING** status and are re-evaluated on the next scheduler polling tick. Once running executions complete and slots become available, pending executions are transitioned to RUNNING automatically. +When either limit is reached, new executions are not rejected. Instead, they remain in `PENDING` status and are re-evaluated on the next scheduler polling tick. Once running executions complete and slots become available, pending executions are transitioned to `RUNNING` automatically. ### Behavior @@ -67,4 +67,4 @@ When working within platform limits, consider the following best practices: 1. **Use alternative patterns**: Consider using event-driven architectures, queuing systems, or batch processing for complex workflows that might exceed depth limits. -1. **Design for workflow concurrency**: If your application triggers many workflow executions simultaneously, be aware that excess executions will queue as PENDING. Design your application to handle this gracefully rather than assuming immediate execution. +1. **Design for workflow concurrency**: If your application triggers many workflow executions simultaneously, be aware that excess executions will queue as `PENDING`. Design your application to handle this gracefully rather than assuming immediate execution.