Repository navigation
Knative Deployment Remains Stuck After Failed Revision Until Revision Is Deleted #16698
Description
Ask your question here:
We’ve noticed that whenever a Knative deployment fails, the deployment can remain stuck in a failed state even after redeploying. The only way we’ve found to recover is to manually delete the failed Knative Revision, then redeploy which is able to proceed normally.
Why does a failed Revision prevent the deployment from recovering automatically? Is this expected Knative behavior, or could it indicate an issue with our configuration?
Additionally, is there a recommended way to handle or automatically recover from failed Revisions so that manual deletion is not required?
Activity
higgsboson1710 commentedon Oct 10, 2026
/assign me
knative-prow commentedon Oct 10, 2026
@higgsboson1710: GitHub didn't allow me to assign the following users: me.
Note that only knative members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide
Details
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
higgsboson1710 commentedon Oct 10, 2026
/assign @higgsboson1710
nardine-t commentedon Nov 6, 2026
Thanks @higgsboson1710 for digging into this and opening #16702 — the root-cause analysis (Route controller treating a failed LRR as permanent even when LCR points at a newer in-flight revision) matches what I'm seeing.
For anyone hitting this: the only workaround today is deleting the failed Revision to force re-reconciliation, which isn't great for automated pipelines.
@dprotaso @dsimansk @skonto — could one of you run /ok-to-test on #16702 so CI can run, and take a look when you have a chance? Happy to help test against a reproduction if useful.