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

Relationships

#1865 Docs: fix incorrect write-bearing classification claim in failure-semantics.md

Opened by stack72 · 8/27/2026· Shipped 8/28/2026

What changed

content/manual/reference/remote-execution/failure-semantics.md in swamp-club/swamp-club states:

"The distinction between no-write and write-bearing is declared at the step level in the workflow definition. The orchestrator does not inspect step behavior at runtime — it relies on the declared step metadata."

This was never true — the orchestrator has always inferred write-bearing status at runtime from data-plane writes (writesByDispatch in dispatch_service.ts).

What needs to change

swamp-club/swamp#1784 adds a writes: true step-level declaration that forces fail-instead-of-redispatch. After that PR merges, the docs should describe both mechanisms:

  1. Runtime inference (default): The orchestrator tracks whether a dispatch performed any durable data-plane write. This is automatic.
  2. Step-level declaration (writes: true): For steps with external side effects (API calls, kubectl, SSH) that don't call writeResource. Inheritable: step > job > workflow.

The current text should be replaced to accurately describe both paths and when writes: true is necessary.

  • swamp-club/swamp#1784 (the code fix)

Automoved by swampadmin from https://github.com/swamp-club/swamp/issues/2290

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 4 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

8/28/2026, 12:17:22 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack728/27/2026, 11:58:13 PM

Sign in to post a ripple.