-
Notifications
You must be signed in to change notification settings - Fork 15
Description
Description
When a TemporalWorkerDeployment custom resource is deleted, the controller does not remove the corresponding Temporal worker deployment (and its versions) from the Temporal Server. Today the controller reconciles only creation/update paths, which leaves a stale deployment record behind.
Context
In my team's project we run 2 types of workers: one long-lived worker for workflow logic and a short-lived worker spun up per workflow run to process its activities (so we never share queues across runs). Each run creates a worker deployment, deletes the CRD once finished (usually within a day). With potentially thousands of workflows running daily, we can end up with many stale and short-lived worker deployments.
Questions for the maintainers
Was there a deliberate rationale for skipping deletion (e.g., audit or durability concerns)?
Are there recommended scripts or best practices today for pruning stale worker deployments?
With the model of short lived workers, besides database growth, are there other downsides—memory pressure, lookup costs, UI/API clutter? Any mitigation/guidance that would help teams with this pattern?
Does the “short lived workers deployments” pattern align with how the Worker Controller is intended to be used, or is there a better approach you recommend?