[Feature Request] Allow configurable Parallel Block concurrency limit beyond 20
Maintainer thường phản hồi trong vòng 1 ngày
@sahooarnav2007-gif đang làm issue này rồi.
Từ ngày 26/10/2026.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- typescript
- Lĩnh vực
- backend
Hướng nghiên cứu
Start by locating the Parallel Block implementation and reading how its current batch limit is applied. Then trace how concurrency is handled for nested blocks and different task types. Done means a chosen approach lets users run larger parallel workloads while making the concurrency limit clear and configurable or appropriately raised.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Feature Request: Increase or remove the hard cap on Parallel Block batch size (currently limited to 20)
Current Behavior
The Parallel Block currently enforces a maximum batch size of 20 concurrent executions. When the number of items exceeds this limit, the block automatically falls back to serial batching — processing 20 at a time and waiting for each batch to complete before starting the next.
Problem
This hard cap of 20 is unnecessarily restrictive for use cases that do not involve LLM calls or external API rate limits. For example:
- Processing 50–100 items through pure compute tasks (data transformation, formatting, rule-based routing, math operations)
- Nested Parallel Blocks (Parallel inside Parallel) where the outer block fans out to N branches and each inner block also runs M tasks concurrently — the 20-limit applies at every level independently, causing compounding serial batching even when no rate-limited resources are involved
- Workflows where all parallel tasks are self-contained Function blocks with zero external I/O
In these scenarios, the 20-item cap forces unnecessary sequential waiting, increasing total execution time without any technical justification.
Proposed Solution
Please consider one or more of the following approaches:
- Raise the default cap from 20 to at least 50 or 100
- Allow user-configurable concurrency limit — let users set their own maxConcurrency value per Parallel Block (e.g. 1–200), so they can tune it based on their actual workload and resource constraints
- Distinguish between LLM and non-LLM tasks — apply a conservative default only when the inner blocks contain Agent/LLM nodes, and use a higher (or unlimited) default for pure compute tasks
Use Case Example
With a fixed cap of 20, this degrades into multiple serial batches even though the hardware and platform have no real constraint preventing full concurrency.
Expected Behavior
Users should be able to configure maxConcurrency freely per Parallel Block, or at minimum have a significantly higher ceiling (50–100), so that non-LLM parallel workloads can execute at full speed without artificial bottlenecks.
Why This Matters
Workflow automation platforms derive much of their value from true parallelism. Capping concurrency at 20 — regardless of workload type — undermines this core value proposition for power users who need high-throughput, non-LLM parallel processing.
Thank you for considering this improvement!
- Ngôn ngữ chính
- TypeScript
- Star
- 29.8k
- Fork
- 3.9k
- Merge trung bình
- 1 giờ 44 phút
- Pull request đã merge (30 ngày)
- 841
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của simstudioai/sim
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
simstudioai/sim#9831 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
v2 API rate limits self-hosted installs by IP even with billing disabledCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 75/100
simstudioai/sim#8452 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Railway template generates invalid ENCRYPTION_KEY (should be 64-char hex string)Có thể làm lại được @sahooarnav2007-gif đã nhận 15 ngày trước và không có pull request nào đang mở. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
simstudioai/sim#6246 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
simstudioai/sim#1204 · 8 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
simstudioai/sim#9734 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của simstudioai/sim
Issue tương tự
-
Bug: Cloudflare Pages static _redirects identity rule causes RSC Flight to reload as HTMLCó thể đã có người làm @Donvero đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Mantitup-Org/vista#210 ·
-
status: waiting for maintainer
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
mui/material-ui#49751 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
diplodoc-platform/transform#1184 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
JonasKruckenberg/imagetools#973 ·
Maintainer thường phản hồi trong vòng 1 ngày