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

Relationships

#1465 Remote execution tutorial: sample runner output is missing the stdout line that #1462 restored

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

Small one-line docs fix, filed as a follow-up to #1461 because that issue is shipped and swamp issue ripple --reopen won't reopen a shipped issue (Cannot reopen issue in status "shipped". Expected "closed".). I've left the detail as a comment there too; this exists so the remaining edit is actually on a list.

The remote execution tutorial sample runner output is missing the step's stdout line, which the CLI does print again as of the #1462 fix.

Verified on swamp 20260729.212638.0-sha.45d9ed58, linux/aarch64, from a clean swamp repo init.

What happened

#1461 and #1462 fixed the same symptom from opposite ends, and the two landed at cross purposes:

  • #1462 (runner) restored inline streaming of remote step stdout.
  • #1461 item 3 (docs) edited the sample output to remove the │ executed on a worker line.

Net effect: the line is back in the CLI and gone from the page.

This is partly on how I filed the original report — I split the runner bug out to #1462 and noted on #1461 that item 3 should be resolved there rather than by editing the docs, but the docs edit treated item 3 as a docs fix as well. Items 1 and 2 of #1461 were both fixed correctly, and I've confirmed those separately on that issue.

Current page

  build │ step echo-on-worker · remote-echo · execute · start
  build │ done echo-on-worker in 729ms
  build │ completed in 729ms

Actual output

 system │ Starting workflow remote-demo · 21:57:54 UTC

  build │ start 21:57:54 UTC
  build │ step echo-on-worker · remote-echo · execute · start 21:57:54 UTC
  build │ executed on a worker
  build │ done echo-on-worker in 675ms · 21:57:54 UTC
  build │ completed in 675ms · 21:57:54 UTC

 system │ Completed workflow remote-demo succeeded in 695ms · 21:57:54 UTC

Suggested fix

Restore the single line build │ executed on a worker to the sample output block, between the step echo-on-worker … and done echo-on-worker … lines.

Worth restoring rather than leaving out, because that line is the tutorial's only visible evidence for the sentence immediately following the block:

The step ran on the worker, not locally. The orchestrator routed it based on the target field, the worker executed it, and the result flowed back through the orchestrator to the workflow runner.

Without it a reader sees a step that succeeded but apparently produced nothing — the same confusion the original report was about, just from the other direction. It's also the payoff of the whole tutorial: the string echoed by a model on a separate process showing up in your local runner output.

Not part of this ask

The updated sample also drops the · HH:MM:SS UTC suffix that the CLI prints on each line. Eliding timestamps that vary per run seems like a sensible choice for a documentation sample, so I'd leave that alone — noting it only so the omission reads as deliberate rather than as a second thing to fix.

Aside on --reopen

Not worth an issue of its own, but ripple --reopen can't express "this shipped and then regressed" — shipped isn't reopenable, only closed. If post-ship regressions on docs pages are common enough, allowing a reopen from shipped (or a distinct regressed status) would save filing a follow-up like this one. Entirely take-it-or-leave-it.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 3 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

7/29/2026, 10:34:49 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack727/29/2026, 10:08:01 PM
Editable. Press Enter to edit.

stack72 commented 7/29/2026, 10:35:19 PM

Thanks @jasonbarnett for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.