Queue system & execution monitoring

How WP-PFWorkflow schedules, executes, retries, and monitors workflow runs.

Execution lifecycle

A workflow is triggered (manual, scheduled, webhook, WP hook, etc.)
The trigger creates an execution record with status queued
pfw_cron_tick picks up the job and sets status to running
Each node executes in sequence; timeline events are recorded
On completion: status → completed; on failure: status → failed
On delay node: execution pauses, a resume job is enqueued for the future
On approval gate: execution pauses with awaiting_approval

Execution states

State	Meaning
`queued`	Waiting to be picked up by the queue runner
`started`	Queue runner has claimed this execution
`running`	Nodes are being executed
`completed`	All nodes finished successfully
`failed`	A node failed and no error handler caught it
`cancelled`	Operator cancelled the execution
`stopped`	A Stop node was reached intentionally
`awaiting_approval`	Paused at an Approval Gate
`duplicate`	Idempotency check detected a duplicate

Monitoring executions

Editor: Click a workflow → "Executions" tab → see status, timeline, logs
REST: GET /pfw/v1/workflows/{id}/executions with filter params
Support package: GET /pfw/v1/workflows/{id}/executions/{eid}/support — full timeline + logs + replay data

Resuming and replaying

Resume from step: Continue a failed/cancelled execution from any node via POST /pfw/v1/workflows/{id}/executions/{eid}/resume
Replay: Replay a saved execution from a support package
Cancel: Stop a running execution via POST /pfw/v1/workflows/{id}/executions/{eid}/cancel

Dead Letter Queue (DLQ)

Outbound webhook requests that exhaust their retry budget (5 attempts) are moved to the DLQ (pfw_outbound_request_log table with status = dlq). You can inspect the DLQ via the outbound request log and manually retry or discard entries.