Skip to content

Add rate_limiting_active field to TaskQueueStats#818

Open
rkannan82 wants to merge 7 commits into
mainfrom
kannan/rate-limiting-active-field
Open

Add rate_limiting_active field to TaskQueueStats#818
rkannan82 wants to merge 7 commits into
mainfrom
kannan/rate-limiting-active-field

Conversation

@rkannan82

@rkannan82 rkannan82 commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

What

Adds bool rate_limiting_active to TaskQueueStats proto 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

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>
rkannan82 and others added 2 commits July 6, 2026 22:08
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@rkannan82 rkannan82 marked this pull request as ready for review July 7, 2026 05:11
@rkannan82 rkannan82 requested review from a team July 7, 2026 05:11
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Comment thread temporal/api/taskqueue/v1/message.proto Outdated
// worker instance.
float tasks_dispatch_rate = 4;

// Whether the task queue's whole-queue rate limit is currently blocking dispatches. When true, adding more

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(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.

rkannan82 and others added 2 commits July 7, 2026 11:02
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@rkannan82 rkannan82 requested a review from Sushisource July 7, 2026 18:05
Comment on lines +151 to +153
// This reflects instantaneous state at the time of the query. If worker throughput is close to the rate
// limit, this value may alternate between true and false across successive queries. Consumers should
// apply their own smoothing or hysteresis to avoid oscillating scaling decisions.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wondering if this is the right semantics or more of a sliding window (say 30s to be consistent with task add/dispatch rate fields)?

Also, what instantaneous mean? does it mean that at this moment a task is blocked behind the limiter.allow?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the concern is complexity in server, we already have sliding window taskTracker used for add/dispatch rates. so it shouldn't be much work.

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants