ores.workflow.workflow_step

1. Flags
2. Natural keys
3. Columns
4. SQL
- 4.1. Flags
5. Foreign keys
- 5.1. workflow_id
6. Indexes
- 6.1. workflow_id
7. C++
8. See also

Records the execution of one step in a saga workflow, including the step index, name, status, request/response payloads, and timing. Steps reference their parent workflow instance via workflow_id.

1. Flags

2. Natural keys

3. Columns

3.1. id

UUID primary key for the workflow step.

3.2. workflow_id

FK reference to the parent workflow instance.

3.3. step_index

Zero-based ordinal position of this step within the workflow. Negative values denote compensation steps.

3.4. name

Human-readable step name, e.g. 'save_party'.

3.5. state_id

FK to the FSM state record (ores_workflow_fsm_states_tbl) for this step.

3.6. request_json

Serialised JSON payload sent to the downstream service for this step.

3.7. response_json

Serialised JSON response received from the downstream service.

3.8. error

Human-readable error message if the step failed.

3.9. step_log_json

Opaque log entries emitted while the step ran, held as serialised JSON. The query surface returns them beside the step's result.

3.10. command_subject

NATS subject to which the step command was published.

3.11. command_json

Serialised JSON command payload published to the domain service.

3.12. command_published_at

Timestamp when the step command was published to NATS. The engine writes it when it dispatches or re-dispatches the step, and the deadline pass reads it to judge the step's silence, so a caller editing the step never states it.

3.13. idempotency_key

Idempotency key (echoes the step UUID) sent as X-Workflow-Step-Id header.

3.14. compensation_subject

NATS subject for the compensation command. Empty if this step has no compensation.

3.15. compensation_json

Serialised JSON compensation command payload, populated when compensation is triggered.

3.16. started_at

Timestamp when the step began executing. The engine writes it with the row it creates at dispatch, so a caller editing the step never states it.

3.17. completed_at

Timestamp when the step reached a terminal state. The engine writes it from its state funnel, so a caller editing the step never states it.

4. SQL

4.1. Flags

5. Foreign keys

5.1. workflow_id

6. Indexes

Every step read is scoped by its workflow, which is also the generated parent-scoped list's filter, so this index is its hot path.

6.1. workflow_id

7. C++

7.1. Flags

7.2. Repository

Reads rely on the row-level security policy instead of an application-level tenant_id predicate, for the reason the instance model states: the engine holds the system tenant and must read back the steps it wrote for another tenant's run, and the policy is what keeps one tenant out of another's steps.

7.3. Domain includes

#include <optional>
#include <string>
#include <boost/uuid/uuid.hpp>

7.4. Conventions

7.5. Custom repository methods

8. See also

ores.workflow — component group overview.