Cancelled workflows are recorded as Failed in duroxide.executions status

[pinodeca]

Summary

Cancelled workflows can be recorded as Failed in duroxide.executions.status, making cancellations indistinguishable from real failures when querying execution rows.

Expected behavior

Cancelled executions should have a distinct terminal status, such as Cancelled, so queries and dashboards can separate user-requested cancellation from failures.

At minimum, the status vocabulary exposed through df.status() and duroxide.executions.status should agree on terminal states, even if casing differs.

Actual behavior

After cancelling a workflow:

• df.status(instance_id) can report cancelled.
• History events show cancellation details.
• duroxide.executions.status records the execution as Failed.

Repro shape

1. Start a long-running workflow.
2. Cancel it with df.cancel(instance_id, reason).
3. Query df.status(instance_id).
4. Query duroxide.executions.status for the same instance.
5. Observe that the durable function status and execution status disagree on whether the terminal state is cancellation or failure.

Impact

Failure dashboards overcount real failures, retry logic can treat user cancellations as retryable failures, and consumers must inspect history payloads to identify cancellations.

[pinodeca]

Todd J. Green (@tjgreen42) does your #258 address this case? If not, would it make sense to fold it in?

[tjgreen42]

Pino de Candia (@pinodeca) I think this should remain open as a separate issue because the cause is a difference in modeling rather than a state drift due to separation of transactions. #258 will fix the user-visible public status APIs by fixing the state drift and partially address this ticket. But to resolve the internal state modeling inconsistency we need a new duroxide Cancelled state. Since it's not user-visible, probably lower priority.