Problem
The production Update Deployed Flows guide currently says to:
- deprecate old workers;
- deploy the new function;
- wait for cron to start it.
It does not disable the corresponding pgflow.worker_functions row before deprecation. While that row remains enabled, ensure_workers() may start another instance of the old deployed function between deprecation and the new function deployment.
The production upgrade guides for 0.12.0 and 0.13.1 already document the complete fence.
Required documentation
Use one production sequence consistently:
- Record the affected functions that are currently enabled.
- Set those
pgflow.worker_functions rows to enabled = false.
- Deprecate their live workers.
- Wait until every affected worker has
stopped_at IS NOT NULL.
- Deploy every affected worker function while the rows remain disabled.
- Re-enable only the functions recorded in step 1.
- Confirm that new workers start and heartbeat.
For a deployment that changes several cooperating worker functions, disable, stop, and deploy the complete affected set before re-enabling any member.
Acceptance criteria
Problem
The production Update Deployed Flows guide currently says to:
It does not disable the corresponding
pgflow.worker_functionsrow before deprecation. While that row remains enabled,ensure_workers()may start another instance of the old deployed function between deprecation and the new function deployment.The production upgrade guides for 0.12.0 and 0.13.1 already document the complete fence.
Required documentation
Use one production sequence consistently:
pgflow.worker_functionsrows toenabled = false.stopped_at IS NOT NULL.For a deployment that changes several cooperating worker functions, disable, stop, and deploy the complete affected set before re-enabling any member.
Acceptance criteria
update-deployed-flowsincludes the disable and re-enable steps with copyable SQL.