Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Bug: v1.6's delete-protection finalizer is never removed from migrated TemporalWorkerDeployment/TemporalConnection, so they stay Terminating after the v1.7 migration

Aperta
  • Qualcosa non va?
#644 2 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@niyomukiza-mechack ci sta già lavorando.

Dal 12/10/2026.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
57/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, kubernetes
Ambito
backend, devops

Direzione di ricerca

Start by reading deprecated_reconciler.go and trace how the deprecated reconcilers release temporal.io/migration-guard; compare that with the v1.6 finalizer behavior described in the issue. Check the migration tests and add coverage for migrated objects that still have temporal.io/delete-protection. Done means the old objects can finish deletion after ownership transfers, without running server-side cleanup on them.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

After migrating from v1.6 to v1.7 (TemporalWorkerDeployment → WorkerDeployment, TemporalConnection → Connection), the old objects stay in Terminating forever. The migration itself succeeds: the new WorkerDeployment adopts the Deployments, the old object is labelled migrated, and the deprecated reconciler releases temporal.io/migration-guard. But the old objects still carry the temporal.io/delete-protection finalizer that v1.6 added, and nothing in v1.7+ ever removes it from the deprecated kinds.

Versions
  • Controller: v1.6.0 (chart 0.25.0) → v1.7.1 (chart 0.28.1), CRDs chart upgraded first as documented. The same code is still present in v1.12.0.
  • Applied with GitOps (Argo CD); same steps as docs/migration-crd-rename.md Step 3: the manifests change kind, so the old objects are deleted and the new ones created in one sync.
Steps to reproduce
  1. Run v1.6.0 with a TemporalWorkerDeployment and a TemporalConnection. v1.6's WorkerDeploymentReconciler adds temporal.io/delete-protection to both (worker_controller.go, finalizerName).
  2. Upgrade the CRDs, then the controller to v1.7.x.
  3. Replace the manifests with WorkerDeployment / Connection of the same names (this deletes the old objects).
Expected

Per the migration guide: "The migration-guard finalizer holds each deprecated resource in Terminating state until the controller confirms ownership transfer is complete, then removes the finalizer and lets the deletion finish."

Actual

The WorkerDeployments and Connection reconcile and the workers keep running on the new objects, but the old objects never finish deleting:

$ kubectl get temporalworkerdeployment <name> -o jsonpath='{.metadata.finalizers}'
["temporal.io/delete-protection"]

migration-guard is gone (the migrated label is set), and only delete-protection remains. For an Argo CD application this blocks the sync: the old objects never go away, so the app stays out of sync and a release that waits on it times out.

Cause

From v1.7 the deprecated kinds are handled by DeprecatedTWDReconciler / DeprecatedTCReconciler, which only add and remove temporal.io/migration-guard. The comment in deprecated_reconciler.go says that is deliberate ("intentionally distinct from the existing temporal.io/delete-protection finalizer, which lives on WorkerDeployment/Connection"). That reasoning holds for objects created after v1.7. But every object that existed under v1.6 already carries delete-protection, and since the WorkerDeploymentReconciler no longer reconciles the old kinds, nothing removes it.

Workaround

Once migration is confirmed, remove the leftover finalizer, guarded so that it only acts when delete-protection is the last finalizer left (that is, after migration-guard was released):

kubectl -n <ns> patch temporalworkerdeployment <name> --type=json -p='[
  {"op":"test","path":"/metadata/finalizers","value":["temporal.io/delete-protection"]},
  {"op":"remove","path":"/metadata/finalizers"}]'

Same for temporalconnection. This made no Temporal API call: the server-side Worker Deployment stays owned by the new WorkerDeployment, and the Kubernetes Deployments (owned only by the new object by then) are untouched.

Suggested fix

When the deprecated reconcilers release migration-guard on a migrated object, also remove temporal.io/delete-protection from it. The new WorkerDeployment / Connection already owns the server-side cleanup that finalizer was for, so this cleanup must not run for the old object. Alternatively, document the step in the migration guide, in the same way the downgrade guide already covers re-adding delete-protection.

Lingua principale
Go
Stelle
197
Fork
79
Merge medio
3g 4h
PR unite (30g)
23

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di temporalio/temporal-worker-controller

Tutte le issue di temporalio/temporal-worker-controller

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.