Skip to main content
Version: 3.4.x

Workflow and Task Mechanics

Workflow execution and Task assignment​

Workflow execution starts with POST /workflows/{id}/runs.

  1. The Client requests a Workflow Run for a registered Workflow.
  2. The Server checks that no other WorkflowRun is already active for the same device.
  3. The Server creates and stores the WorkflowRun, then triggers execution of the first Step.
  4. The current Step is converted into a Task and stored in PENDING state.
  5. Then TaskRegisteredEvent is published, and the server broadcasts that state on two channels:
    • device Moth channel: TASK_REGISTERED
    • client event channel: TASK_REGISTERED
  6. After receiving the Task, the Device reports status through the start, complete, reject, and abort APIs.
  7. Depending on the result, the Server starts the next Step or transitions the WorkflowRun to completed, failed, or retrying.

Retry policy​

  • A Workflow Run does not necessarily end immediately on failure; it may re-execute the current Step.
  • The maximum retry count is currently a server implementation policy that is not exposed through /server-settings.
  • If abort includes a failPoint, it is reflected in the first Step payload of the restarted Workflow Run.

Task status tracking in the web Client​

The Task-status tracking path is Device → CoBiz Server → Moth → Client.

  1. The Device calls POST /tasks/{id}/start|complete|reject|abort.
  2. The Server stores the Task state in the DB.
  3. A Task domain event occurs on every state change.
  4. The Server publishes that event on Moth's client channel.
  5. After receiving the event, the Client re-fetches Task or Workflow Run details and reflects the latest state.

Task state transitions​

  • PENDING: created by the server and not yet started by the device
  • IN_PROGRESS: the device reported start
  • COMPLETED: the device reported normal completion
  • REJECTED: the device refused to execute the work
  • ABORTED: aborted because of user cancelation, device disconnect, Workflow stop, or a similar reason

Information refreshed by the Client​

  • current running Task
  • Workflow Run history
  • notifications and toast messages
  • execution impact caused by device state changes