Skip to content

Workflow with name

DotFlow accepts an optional name kwarg that labels the workflow on the managed server. When omitted, the name defaults to the machine hostname — useful to distinguish runs from different hosts in the dashboard.

Why set a name

  • Dashboard clarity — runs grouped by purpose (etl-nightly, report-monthly) instead of by host
  • Idempotent start — combined with a fixed workflow_id, a re-run of the same DotFlow instance returns the existing Manager instead of starting a duplicate
  • Search / filter — managed-mode users can find runs by human-readable label

Example

"""Workflow with a custom name.

``DotFlow`` accepts an optional ``name`` kwarg that is sent to the managed
server when the workflow is registered. When omitted, the name defaults to
the machine hostname — useful to distinguish runs from different hosts in
the dashboard.
"""

from dotflow import DotFlow, action


@action
def step_one():
    return "done"


def pipeline() -> DotFlow:
    workflow = DotFlow(name="etl-nightly")
    workflow.task.add(step=step_one)

    return workflow


if __name__ == "__main__":
    pipeline().start()

Default behavior

Without name, dotflow uses socket.gethostname():

workflow = DotFlow()  # name = "macbook-pro.local" (or similar)

This is fine for ad-hoc local runs. For production pipelines, prefer an explicit semantic label.

Idempotent start

DotFlow.start() is idempotent for a given task signature. Calling start() twice on the same instance returns the original Manager and logs a warning:

workflow = DotFlow(name="etl-nightly")
workflow.task.add(step=step_one)
m1 = workflow.start()
m2 = workflow.start()  # warns: duplicate call ignored
assert m1 is m2

This protects against double-execution when the same factory is invoked twice in a job runner.

References