Split the shared Task Queue guidance by compute provider - #5177
Open
lennessyy wants to merge 4 commits into
Open
Split the shared Task Queue guidance by compute provider#5177lennessyy wants to merge 4 commits into
lennessyy wants to merge 4 commits into
Conversation
The section described Lambda behavior only, and said Serverless Workers are invoked on sync match failure alone, which the note earlier on the page already contradicts. Split the section by execution model. A Cloud Run pool instance polls continuously, so a running pool takes a share of the Task Queue rather than only the overflow, and acts as spillover only at zero instances.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
📖 Docs PR preview links |
Contributor
There was a problem hiding this comment.
Pull request overview
Updates Serverless Worker scaling documentation to distinguish AWS Lambda and GCP Cloud Run behavior.
Changes:
- Explains provider-specific Task Queue sharing.
- Clarifies risks when both Worker groups scale dynamically.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Each provider's Autoscaling section now carries a subsection on sharing a Task Queue with long-lived Workers, matching how the index page already delegates autoscaling, lifecycle, and versioning by provider. The index section keeps the shared framing, the caution that applies to both providers, and links to the two subsections.
The two providers size their Workers from different signals, so the guidance differs. Lambda invokes on sync match failure or backlog, so a long-lived fleet that keeps up produces neither and the Serverless Workers act as spillover. Cloud Run sizes the pool from the arrival rate on the Worker Deployment Version's Task Queues, which counts Tasks the long-lived Workers are already processing. The pool scales up to duplicate their capacity, so the guidance is to give the Serverless Workers their own Task Queue. The index section becomes a pointer to both, since the two cautions no longer share content.
lennessyy
changed the title
The recommendation not to share a Task Queue was in a caution at the end of the subsection. Put it first, followed by the consequence and then the mechanism, and drop the now-redundant admonition.
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
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
The Serverless Workers "Scaling with long-lived Workers" section described AWS Lambda behavior only. The two compute providers size their Workers from different signals, so the guidance is now a subsection on each provider page.
Lambda invokes a Worker on sync match failure or backlog, so a long-lived fleet that keeps up produces neither and the Serverless Workers act as spillover capacity.
Cloud Run sizes the pool from the arrival rate on the Worker Deployment Version's Task Queues, which counts Tasks the long-lived Workers are already processing. The pool scales up to duplicate their capacity, so the guidance is to give the Serverless Workers their own Task Queue.
The Cloud Run behavior is read from
rate_based.goontemporal-auto-scaled-workersmain, not verified by testing. Worth a check from someone on the WCI side before merge.