Skip to content

Document the worker-function enable fence for production deployments #654

Description

@jumski

Problem

The production Update Deployed Flows guide currently says to:

  1. deprecate old workers;
  2. deploy the new function;
  3. 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:

  1. Record the affected functions that are currently enabled.
  2. Set those pgflow.worker_functions rows to enabled = false.
  3. Deprecate their live workers.
  4. Wait until every affected worker has stopped_at IS NOT NULL.
  5. Deploy every affected worker function while the rows remain disabled.
  6. Re-enable only the functions recorded in step 1.
  7. 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

  • update-deployed-flows includes the disable and re-enable steps with copyable SQL.
  • The guide preserves the prior enabled-function set instead of enabling every registered function.
  • The wait query scopes worker rows to the affected function names and requires zero live rows.
  • Multi-function deployments describe one fence around the complete affected set.
  • Worker-management and production-update pages link to one consistent sequence.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions