Repository navigation
Phase 2.4: engine-side auto-compensation (deferred until real driver needs it) #704
Description
Tracker for Phase 2.4 deferred candidates from workflow#695 Phase 2.5+ design. Currently no active driver requires this.
Scope (when revived)
-
Engine auto-compensation — when wfctl-side hook fails post-driver-success, engine attempts inverse RPC (
Deleteon created,Createon deleted). RecordsActionStatusCompensatedorActionStatusCompensationFailed. Requires per-driverCompensablecapability declaration; partial-state error handling; coordinated cascade. -
Per-plugin emission of COMPENSATED — plugin v_next opt-in; plugin author decides emission semantics (e.g., DO deferred-flush could emit COMPENSATED on partial-flush success).
-
Per-resource-type compensation policy — per-Driver capability declaration.
Affordances already in place (workflow v0.57.1)
interfaces.ActionStatusCompensatedenum value reserved (interfaces/iac_state.go:168) — engine does NOT emit; plugins may emit if they implement own compensationinterfaces.ActionStatusCompensationFailedenum value reserved — semantically defined for post-driver-success hook failureIaCProviderFinalizer.FinalizeApply(Phase 2.5) provides per-driver post-loop hook point that future compensation logic would extend
Why deferred
No driver currently emits COMPENSATED. Per memory project_open_followup_queue.md: "Deferred until a real driver needs it." Implementing speculatively risks design lock-in to a wrong abstraction. Wait for a concrete consumer (likely DO Spaces key rotation, or App Platform replace-with-rollback) to drive the requirements.
References
- ADR 0040 (v2 action lifecycle + provider compatibility) — invariant 2 (engine populates one ActionOutcome per PlanAction)
- workflow#695 Phase 2.5 (FinalizeApply) — established post-loop hook surface this would build on
- workflow#698 Phase 2.3 (ActionStatus enums) — established the COMPENSATED/COMPENSATION_FAILED values
Activity
intel352 commentedon Jun 1, 2026
Audit result: still relevant as intentionally deferred design scope.
Verified against latest
origin/main:ActionStatusCompensated/ActionStatusCompensationFailedare reserved andIaCProviderFinalizer.FinalizeApplyexists, but there is no engine-side auto-compensation implementation. That matches this issue's stated intent: keep it deferred until a concrete driver requires it.intel352 commentedon Jun 3, 2026
Rechecked with
workflow-plugin-infralatestorigin/master(7d3b9ee, 2026-06-03 local fetch). That repo is currently an infra-admin/module surface that delegates lifecycle work to configured IaC providers; it does not introduce a concrete post-driver-success hook failure or provider-specific compensation semantic that would justify reviving engine-side auto-compensation in workflow core now.\n\nConclusion: still relevant, but still intentionally deferred until a real provider/driver path needs it. No workflow-core implementation for #704 in this batch.intel352 commentedon Jun 3, 2026
Rechecked after workflow PR #850 merged and after fetching current defaults.
Evidence:
workflowlatestorigin/main:80c50ebd50d08c9f24b30c0933e73f831032e81d.workflow-plugin-infralatestorigin/master:002c6a27c3ff9246ba6aebc9ed5c81cd7720b411.workflow-plugin-infrais still an abstractinfra.*module/admin surface. It delegates provider behavior to configured IaC provider plugins and does not add a concrete post-driver-success hook failure path, compensable resource capability, or provider-owned compensation semantic.workflowcore still has the intended Phase 2.3/2.5 affordances:ActionStatusCompensated/ActionStatusCompensationFailed,ApplyPlanHooks.OnPlanComplete, andIaCProviderFinalizer.FinalizeApply. Post-hook failures are surfaced asCOMPENSATION_FAILED; the engine still does not attempt speculative inverse RPCs.Conclusion: #704 remains relevant as deferred design scope, but still should not be implemented in workflow core or moved into workflow-plugin-infra yet. The next action should wait for a concrete provider/driver path that can define
Compensablebehavior and failure semantics without guessing.intel352 commentedon Jun 6, 2026
Re-triaged as part of the current issue sweep.
I’m leaving this deferred rather than implementing a speculative auto-compensation layer now. The issue’s prior conclusion still holds: the tracker should be driven by the first real driver that needs compensation semantics so the API, persistence model, and failure modes are grounded in an actual provider workflow instead of a placeholder abstraction.
No PR filed for this one in this sweep; it remains open as the tracker for that future driver-backed implementation.