Add rate_limiting_active field to TaskQueueStats#818
Merged
Conversation
When a task queue's whole-queue rate limit is blocking dispatches, auto-scaling systems should suppress scale-up since more workers cannot increase throughput. This boolean surfaces that state. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sushisource
reviewed
Jul 7, 2026
| // worker instance. | ||
| float tasks_dispatch_rate = 4; | ||
|
|
||
| // Whether the task queue's whole-queue rate limit is currently blocking dispatches. When true, adding more |
Member
There was a problem hiding this comment.
What are the semantics of "currently" here? Will this flicker on and off if worker throughput is nearly equal to the rate limit? I think adding a bit more detail to the doc would be useful here.
And, internally, if that is possible, it might make sense to apply some smoothing/debounce or something so scalers don't oscillate
Contributor
Author
There was a problem hiding this comment.
(updated comment) This is instantaneous value, and can flicker. We expect the consumer to handle any smoothing. I didn't want to add complexity right now to server.
Contributor
Author
There was a problem hiding this comment.
After discussing with Shahab, changed the semantics from instantaneous to a window (last 30 seconds).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ShahabT
reviewed
Jul 7, 2026
The flag represents whether rate limiting is blocking dispatches, without distinguishing which limiter is responsible. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sushisource
approved these changes
Jul 7, 2026
ShahabT
approved these changes
Jul 7, 2026
rkannan82
added a commit
to rkannan82/temporal
that referenced
this pull request
Jul 8, 2026
v1.63.2 includes the rate_limiting_active field (temporalio/api#818). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds
bool rate_limiting_activetoTaskQueueStatsproto message.Why
Auto-scaling systems need to know when backlog growth is caused by rate limiting rather than insufficient worker capacity. When the whole-queue rate limit is blocking dispatches, scaling up workers doesn't help — the bottleneck is the rate limit, not worker count.
Server PR
🤖 Generated with Claude Code