Problem
The Helm memo-transition stop-the-world guard treats desired configuration as proof that the old runtime is gone. It permits the transition as soon as the Server and worker Deployments report zero desired replicas and the scheduler CronJob reports suspend: true.
Scaling and suspension are asynchronous: incompatible or unidentified Server/worker pods can still be terminating, and a scheduler Job started before suspension can still be running. The bootstrap migration may therefore install the dual memo representation while an envelope-only process remains able to read or write memo rows. The documented procedure says the old revision must be fully stopped, but the guard and its upgrade matrix do not prove that condition.
Acceptance criteria
- Keep an upgrade blocked while any managed Server or worker pod using an envelope-only or unidentified image remains active or terminating, even when its Deployment already has zero desired replicas.
- Keep an upgrade blocked while any active scheduler Job or pod from the prior CronJob remains, even after the CronJob is suspended.
- Ignore genuinely terminal or deleted executions so the stop-the-world path becomes available once the old runtime is actually quiescent.
- Preserve ordinary rolling upgrades for verified raw-JSON and dual-representation workloads.
- Add live Helm/Kubernetes upgrade evidence that deliberately holds a terminating Deployment pod and an in-flight scheduler execution across the scale/suspend changes, proves the transition is rejected, then proves it is accepted only after both are gone.
- Align the upgrade procedure with the enforced quiescence check.
Delete when
Delete when an incompatible or unidentified predecessor cannot remain executable during the dual-representation bootstrap after desired replicas reach zero or the CronJob is suspended, with landed cluster-backed evidence for both Deployment and scheduler races.
Problem
The Helm memo-transition stop-the-world guard treats desired configuration as proof that the old runtime is gone. It permits the transition as soon as the Server and worker Deployments report zero desired replicas and the scheduler CronJob reports
suspend: true.Scaling and suspension are asynchronous: incompatible or unidentified Server/worker pods can still be terminating, and a scheduler Job started before suspension can still be running. The bootstrap migration may therefore install the dual memo representation while an envelope-only process remains able to read or write memo rows. The documented procedure says the old revision must be fully stopped, but the guard and its upgrade matrix do not prove that condition.
Acceptance criteria
Delete when
Delete when an incompatible or unidentified predecessor cannot remain executable during the dual-representation bootstrap after desired replicas reach zero or the CronJob is suspended, with landed cluster-backed evidence for both Deployment and scheduler races.