fix(worker): honour temporal-max-parallel-activities flag (EN-1228) - #191
fix(worker): honour temporal-max-parallel-activities flag (EN-1228)#191flemzord wants to merge 1 commit into
Conversation
The flag is registered as a float64 in go-libs, but it was read with GetInt, which fails on a float64 flag and returns 0. The worker option was therefore always 0 (Temporal default = unlimited), so the operator-set limit never took effect. Read it with GetFloat64, and wire it to MaxConcurrentActivityExecutionSize (activity concurrency) rather than TaskQueueActivitiesPerSecond (a queue-wide rate limit), which is what "max parallel activities" means. Behavioural note: the default (10) now actually caps activity concurrency where it previously had no effect.
|
Warning Review limit reached
More reviews will be available in 51 minutes and 52 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
flemzord
changed the title
|
Superseded by #199, which consolidates this change with the related reliability and safety fixes on top of the current main branch. |
1 participant
Problem (H9 — HIGH)
The flag is registered as a float64 in go-libs (
temporal/cli.go).GetInton a float64 flag returns an error (discarded) and0, so the worker option was always0(Temporal default = unlimited) — the operator-configured limit never applied. Separately, "max parallel activities" is a concurrency cap, which maps toMaxConcurrentActivityExecutionSize, not the queue-wide rate limitTaskQueueActivitiesPerSecond.Fix
GetFloat64.MaxConcurrentActivityExecutionSize.Behavioural note: the default (10) now actually caps activity concurrency where it previously had no effect. Worth confirming the default suits production throughput.
Severity: HIGH.