Repository navigation
Worker readiness follows scheduler registration - #2821
Merged
Merged
Conversation
(cherry picked from commit f20ef84ec0a2a975a1ce59be881b653f0d4ef7a7)
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
corcillo
reviewed
Sep 29, 2026
corcillo
reviewed
Sep 29, 2026
… the status path is refused
corcillo
previously approved these changes
Sep 29, 2026
corcillo
approved these changes
Sep 29, 2026
This branch was successfully deployed
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
2 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 and why
A worker pod turned Ready when its container started, not when the worker could take work:
/statusanswers 200 while a component is still initializing, which suits a liveness probe and misleads a readiness probe, and an autoscaler reading pod readiness counted idle time from container start. Thehealthservice now also serves/ready(readiness_path), which answers 503 while anything is initializing or failed. Each worker registers aworkers/<name>indicator that reads Initializing until the scheduler answers itsconnect_worker, Ok while that connection holds, and Initializing again once it is lost and the worker is reconnecting, so only/readydrops and a liveness probe on/statusstays green through a scheduler roll. A readiness probe on/readyturns the pod Ready at registration and not Ready again when it loses the scheduler. The two paths must differ; the same path for both is refused at startup with a message rather than left to panic the router.How was this verified?
health_server_test.rs: the readiness form answers 503 for an initializing component where the plain form answers 200.local_worker_test.rs: the registration flag is off before the scheduler'sConnectionResult, on after it, and off again when the stream ends, reading Initializing rather than Failed.health_server_test.rsalso covers the path defaults and the refusal of a shared path.The docs snippet lint only knew the latest release's reference, so a snippet naming a new field could not pass until the next release; it now reads main's reference as well, regenerated here.
Risk
Low.
/statusis unchanged, and/readyis a new path; a probe has to be pointed at it to change anything. The chart's probe is off by default so older images keep working.AI assistance
An agent drafted the change and I reviewed every line.