GovOPlaN/govoplan-ops
2
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

Document Dataflow recovery operations

Browse Source
This commit is contained in:
zemion
2026-08-03 06:09:52 +02:00
parent e3e0fdaab5
commit e5f4021de9
2 changed files with 4 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+3
View File
@@ -58,3 +58,6 @@ For provider effects, Ops is the status and evidence-chain projection rather
than the reconciliation authority. Follow the owning module's bounded action: than the reconciliation authority. Follow the owning module's bounded action:
for example, reconcile an unknown Mail SMTP command from provider evidence and for example, reconcile an unknown Mail SMTP command from provider evidence and
never retry the original effect merely because its caller state is incomplete. never retry the original effect merely because its caller state is incomplete.
For Dataflow, a database-only run is atomic. A published-output run is forward
recovery: inspect its recorded output digest and sink idempotency key, and do
not start another publication while its state is `outcome_unknown`.
src/govoplan_ops/backend/manifest.py
+1 -1
View File
@@ -139,7 +139,7 @@ manifest = ModuleManifest(
id="ops.runtime-coordination-and-recovery", id="ops.runtime-coordination-and-recovery",
title="Drain runtime nodes and inspect recovery evidence", title="Drain runtime nodes and inspect recovery evidence",
summary="Ops projects shared runtime heartbeats, replica gaps, drain controls, and recovery states that require operator attention.", summary="Ops projects shared runtime heartbeats, replica gaps, drain controls, and recovery states that require operator attention.",
body="Use the runtime table to identify stale or composition-skewed API and worker replicas. Drain before replacement so API readiness closes and workers stop taking new queue work; cancellation is available while the node is still draining. The recovery table reports durable Core recovery operations. A rejected operation is a verified provider rejection and needs no recovery; outcome-unknown and recovery-required operations still require reconciliation through the owning module. Mail SMTP and IMAP APPEND entries use stable attempt identifiers and digest-only evidence: reconcile the Mail command from provider evidence, never by replaying the original effect from Ops. Backup status separately projects only the sanitized deployment verification receipt: a verified status identifies a coordinated recovery point and isolated restore drill, while absent, expired, or invalid evidence blocks a release-changing migration.", body="Use the runtime table to identify stale or composition-skewed API and worker replicas. Drain before replacement so API readiness closes and workers stop taking new queue work; cancellation is available while the node is still draining. The recovery table reports durable Core recovery operations. A rejected operation is a verified provider rejection and needs no recovery; outcome-unknown and recovery-required operations still require reconciliation through the owning module. Mail SMTP and IMAP APPEND entries use stable attempt identifiers and digest-only evidence: reconcile the Mail command from provider evidence, never by replaying the original effect from Ops. Dataflow database-only runs are atomic, while published-output runs use forward recovery: reconcile the recorded output digest and sink idempotency key before allowing another publication. Backup status separately projects only the sanitized deployment verification receipt: a verified status identifies a coordinated recovery point and isolated restore drill, while absent, expired, or invalid evidence blocks a release-changing migration.",
documentation_types=("admin", "user"), documentation_types=("admin", "user"),
audience=("operator", "system_admin"), audience=("operator", "system_admin"),
conditions=( conditions=(