Skip to main content
← Back to list
01Issue
FeatureShippedSwamp Club
Assigneesstack72

Relationships

#1464 Docs: document rollbackOnFailure with safety guidance for external-dependency models

Opened by stack72 · 7/29/2026· Shipped 7/29/2026

Summary

PR #2008 shipped rollbackOnFailure on method definitions (fixing #1430 and #1451). The design doc in design/models.md has a brief section, but the user-facing manual needs comprehensive documentation with prominent safety warnings.

What needs documenting

  1. The rollbackOnFailure field — what it does, how to declare it, what the deferred-latest mechanism means in practice
  2. When to use it — batch operations where partial writes are garbage (instrument readings, bulk transforms, multi-resource provisioning)
  3. When NOT to use it — this is critical safety guidance:
    • Methods that interact with external systems (cloud infrastructure, APIs, databases, instruments) and write data reflecting real-world state that has already changed. If a method provisions 3 VMs and writes their IDs, then fails provisioning VM 4, rolling back the data deletes the records of VMs 1-3 — but those VMs still exist in the cloud. The data layer says they don't exist. This is worse than partial writes.
    • Methods that write-then-throw intentionally (e.g. code-review models that write results then throw on verdict=FAIL)
    • Any method where the writes are the most accurate picture of reality even if the method failed partway
  4. The method author's contract — "my writes are a batch, commit all on success, discard all on failure, I don't need to read back my own writes during execution"
  5. Interaction with workflows — how rollbackOnFailure complements the workflow-level guard field (shipped in #1993) and resume --from (#1444)

Suggested location

content/manual/reference/model-definitions.md — alongside existing method definition documentation. Consider a dedicated "Write Atomicity" subsection with a warning callout for the external-dependency danger.

Why the safety warning matters

The flag name rollbackOnFailure sounds universally good — "of course I want rollback on failure." But for models managing cloud infrastructure, network devices, or any external stateful system, the writes reflect real-world state changes that cannot be un-done by deleting local data. Rolling back the data creates a divergence between what swamp knows and what actually exists. The docs must make this danger impossible to miss.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 6 MOREREVIEW+ 3 MOREPR_MERGED+ 1 MORENOTIFICATION_SKIPPED

Shipped

7/29/2026, 11:02:44 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack727/29/2026, 10:18:03 PM

Sign in to post a ripple.