Fence and reconcile Dataflow runs
This commit is contained in:
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user