Fence and reconcile Dataflow runs

This commit is contained in:
2026-08-03 06:09:53 +02:00
parent e1c092ece7
commit 3fa7a29f48
13 changed files with 1314 additions and 44 deletions
+9 -3
View File
@@ -103,9 +103,15 @@ counts, outcomes, and publication references remain as audit evidence.
Development runs may use the bounded reference backend. Staging and production
runs require the short-lived isolated DuckDB process. A revision must be
promoted from development to staging and then from staging to production before
it can run in those environments. Complete results can be published atomically
through `datasources.publication`; publication is rejected when a source or
result was truncated.
it can run in those environments. Complete results can be published through
`datasources.publication`; publication is rejected when a source or result was
truncated. The provider effect is a forward-recovery boundary rather than an
atomic database operation. Dataflow records the source and output digests before
dispatch, commits a conclusive provider result together with the local run
projection, and exposes an `outcome_unknown` run when acknowledgement is lost.
Such a run is never retried until the sink has been reconciled by its stable
idempotency key. See
[`docs/DURABLE_RUN_RECOVERY.md`](docs/DURABLE_RUN_RECOVERY.md).
## Governed Definitions And Automation