Why can a Helm upgrade with --wait report success while a Job in the chart is still running?

## The gap `--wait` and friends answer one question: *have the resources I applied reached the state they were asked for?* For a Deployment that means the replicas are up and ready. For a Job, the resource has been created and its controller is doing its work - which is, as far as a readiness judgement is concerned, the Job doing exactly what it should. "Finished successfully" is a different condition entirely, and a wait strategy does not gate on it. So the sequence a team hits looks like this. An invoice-rendering worker chart published to an OCI registry by CI grows a data-backfill Job as an ordinary manifest under `templates/`. The pipeline runs `helm upgrade --install ... --wait --timeout 12m`. Helm reports the release deployed after about 38 seconds. The pipeline goes green, the next stage flips traffic, and the backfill is still running six minutes later - and when it fails at minute seven of a 7m14s run, nothing in the release record notices. ## The flag that closes it `--wait-for-jobs` makes Helm hold the release open until the Jobs in the release have completed, before marking it successful. Two properties are worth stating explicitly because interviewers probe both: - **It is an addition to a wait strategy, not a replacement for one.** It is meaningful when Helm is waiting; on a command that does not wait at all there is no wait for it to extend. - **It shares `--timeout`.** There is no separate Job budget. Whatever duration you gave the release now has to cover the rollout *and* the Job's whole runtime. A five-minute default against a seven-minute backfill fails every single time, and the failure message is a timeout, which reads like an infrastructure problem rather than "you asked for something that does not fit". ## The part that bites in production Turning it on changes what a slow or flaky Job costs you. Before, a Job that retried its way through several attempts was invisible to Helm. After, it holds the release open for as long as it keeps retrying, and when the budget runs out the release is recorded failed even though nothing was ever actually wrong with the deployment of the workers themselves. A Job with a generous retry allowance and a long back-off can eat a large timeout on its own. That gives you a genuine design decision rather than a flag to switch on reflexively: - **Is this Job part of the release's definition of success?** A schema migration that the new workers cannot run without, yes. An analytics backfill that can finish whenever, no - gating the deploy on it converts an unrelated data problem into a failed release. - **Does the timeout reflect it?** If you gate on the Job, the budget must be sized from the Job's observed runtime plus the rollout's, with headroom. Otherwise you have built a scheduled false alarm. - **Should it be a hook instead?** Annotating the manifest as a hook moves it out of ordinary release resources and into Helm's hook machinery, which has its own ordering and its own waiting - a different mechanism with different consequences, and a different decision from this flag. ## How to spot it in a live system The symptom is a pipeline that is reliably green and a Job that is reliably not finished. `helm status` shows the release deployed; listing Jobs in the release namespace shows one with completions still outstanding, or a completion timestamp minutes after the release's own. If the deploy stage's duration is dramatically shorter than the work you believe it is doing, that is the tell. ## What to say when asked Name the distinction first - ready is not done - then the flag, then the two consequences: it needs a wait strategy to extend, and it spends the same timeout. Finishing with the judgement call about which Jobs deserve to gate a release is what separates a flag-recall answer from an operating one.