Repository navigation
fix(controller): fail rollouts with invalid Job templates - #657
Open
Chen Yufeiyang (feiiiiii5) wants to merge 1 commit into
Open
Chen Yufeiyang (feiiiiii5) wants to merge 1 commit into
Chen Yufeiyang (feiiiiii5) wants to merge 1 commit into
Conversation
build_job_spec ran inside the Kubernetes API try/except, so a deterministic template or manifest error without a 422/unprocessable/ invalid substring was treated as retryable and the rollout stayed QUEUING forever. Build errors now mark the rollout FAILED; API failures keep the existing retry classification.
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The focused change addresses the rollout hang, preserves API retry behavior, and includes regression coverage with no identified blocking issues.
No open issues 🎉
What changed in this PR
This PR prevents rollouts with invalid Kubernetes Job templates from remaining in QUEUING indefinitely by treating manifest-build errors as terminal failures.
Changes:
- Separates manifest construction from Kubernetes API error handling while preserving existing API retry behavior.
- Centralizes invalid Job failure reporting.
- Adds regression tests for Jinja syntax errors and null Job metadata.
| File | Description |
|---|---|
tests/controller/test_k8s_reconciler_errors.py |
Verifies invalid templates mark rollouts as failed. |
agentlightning/controller/k8s_reconciler.py |
Handles manifest-build failures separately and shares failure reporting. |
Review effort: Balanced
This branch has not been 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
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.
A rollout whose
config.k8s.job_templatecannot render or parse never reaches a terminal state._create_job()callsbuild_job_spec()inside the Kubernetes API try/except, so a deterministic template/manifest error (TemplateSyntaxError, a YAML parse error,metadata: null) is classified as transient unless its message happens to contain422,unprocessable, orinvalid. The rollout staysQUEUING, the controller logs “will retry” on every poll, andAglRolloutManager.enqueue_and_wait_until_completed()waits forever.Manifest construction happens before any Kubernetes request and is deterministic, so retrying the same rollout cannot succeed. This separates the build step from the API call: a build exception marks the rollout
FAILEDwith the validation error, while K8s API failures keep the existing retry classification.Test: the new regression covers a Jinja syntax error and a structurally invalid Job (
metadata: null); both fail on05c7fe1withJob creation failed — will retryand no status patch, and pass here. The controller/server/client/package suites are 75 passed;ruff check/format --checkare clean.Details
The regression mocks
_patch_statusbut exercises the realbuild_job_spec()failures. The trainer-side hang is not executed end-to-end because it requires the optional verl/torch group; it follows from the manager polling until every rollout is terminal. No live Kubernetes cluster is used.