[czpython]

Outside a workflow (a request, a webhook, a command), Workflow.start() enqueues the run in the caller's transaction through DBOS's DBOSClient.enqueue_in_transaction, so the run, its row, and its workflow.scheduled event commit together, and a rollback leaves none of them. Before, start() enqueued in DBOS's own transaction at once, so a request that failed after the start kept a run whose subject row was gone.

• Inside a workflow, body or step, start() keeps DBOS.enqueue_workflow_async, which DBOS records as the workflow's child: a replay finds the run, and runs in flight at deploy recover as before. DBOS.workflow_id picks the path.
• druks.durable.engine.enqueue_in_transaction runs the client call in a savepoint. A held deduplication slot raises DBOSQueueDeduplicatedError; the savepoint drops the collision, and the call returns the holder from workflow_status, or claims the slot again when the holder ended in between. The client stamps the attributes and serializes the input as an in-process enqueue does.
• Run.create_row takes the caller's session. _execute_run and Run.retry write their rows through sessions of their own, as before.
• The workflow_status handle reads queue_name and deduplication_id, and its grace comment no longer says the row commits before the enqueue.
• docs/writing-an-app.md gives the rule beside the duplicate-start rule. Two tests cover a start that rolls back and a second start in the same transaction, and the failed-enqueue test now fails the in-transaction enqueue.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
druks	🟢 Ready	View Preview	Nov 7, 2026, 4:22 PM

💡 Tip: Enable Automations to automatically generate PRs for you.