Skip to main content
← Back to list
01Issue
BugClosedSwamp CLIPublicTeam
Assigneesstack72

Relationships

#1790 Workflow YAML rewritten in place: block-scalar description truncated, file left unparseable, and validate still reports PASSED

Opened by randybias · 8/22/2026

Something in the CLI rewrote three of my workflow YAML files in place, truncated a multi-line description, left the remainder as orphaned text, and produced a file that is not valid YAML — and swamp workflow validate reported PASSED on the result.

Measured on swamp --version 20260822.011157.0-sha.06b61472.

Before (committed, parses clean)

        description: >-
          REDFISH-ONLY. The three host-transport args (hostAddress, hostUsername,
          hostBdf) and hostIdentityContent are NOT passed at all, because there is no way
          to pass them conditionally: the method marks them optional, and its schema
          rejects BOTH '' and null. ...

          CONSEQUENCE, stated rather than hidden: the host rshim and mlxconfig
          fallbacks are UNREACHABLE from this workflow. ...

After the rewrite

        description: Read applied mode via Redfish, falling back to host rshim and mlxconfig

          CONSEQUENCE, stated rather than hidden: the host rshim and mlxconfig
          fallbacks are UNREACHABLE from this workflow. That is correct for its job

The block scalar (>-) was replaced by a single-line value, and the rest of the original block was left in place as unindented continuation text. Because that orphaned text contains a colon, the file no longer parses:

yaml.scanner.ScannerError: mapping values are not allowed here
  in "workflow-bluefield-get-mode.yaml", line 76, column 49

Verified both directions: the committed version parses; the rewritten version does not.

Two separate problems

  1. Data loss. The description was replaced with a one-line summary and the explanatory body orphaned. Across three files the diff was -246 / +165. The lost text was the reasoning for a non-obvious choice — exactly the content that stops the next author undoing it.
  2. swamp workflow validate reports PASSED on the unparseable file. All three validated clean after the rewrite. Whatever parser validate uses accepts input that a standard YAML parser rejects, so the corruption is invisible to the tool most likely to catch it.

Problem 2 is the more serious of the two: a file can be silently corrupted and every in-tool check stays green.

What I was doing

Ordinary read-path work in the repo — swamp workflow validate / evaluate / get, a swamp workflow run, and some swamp vault reads. I did not edit these files by hand in that window. I have not isolated which command performs the rewrite, so I cannot give a single-command repro yet; if you can point me at which subcommands normalise workflow YAML on disk, I will narrow it and follow up.

I restored the three files from git. No data was lost permanently, but it would have been had the working tree not been committed first.

Request: whatever performs this normalisation should round-trip a block scalar without truncation, and validate should fail on a file it cannot parse rather than passing it.

02Bog Flow
✓OPEN✓TRIAGED○IN PROGRESS◉CLOSED+ 1 MOREASSIGNED+ 5 MOREREVIEW

Closed

8/24/2026, 11:54:43 AM

No activity in this phase yet.

03Sludge Pulse
stack72 assigned stack728/23/2026, 8:42:43 PM
Editable. Press Enter to edit.

randybias commented 8/22/2026, 7:54:48 PM

RETRACTING THIS REPORT — it was not a swamp bug. Please close as invalid.

The rewritten files were another agent session's uncommitted edits in a shared working tree, not a rewrite by the CLI. Several sessions operate in one checkout on this host; a peer was mid-way through a conformance pass over exactly these three BlueField workflows, and their in-progress state appeared in my git status as unexplained modifications. They committed the finished work three minutes after I filed this.

I have since tested the read path directly against a clean, committed workflow containing four block scalars: workflow validate, workflow get, workflow list, model type describe and vault list-keys each leave it untouched. Another operator independently reports extension install twice plus vault commands with zero modified workflow files.

So there is no evidence swamp rewrote anything. The unparseable state I reported was a peer's file caught mid-edit.

The one part I would still stand behind, separately and much more weakly: swamp workflow validate reported PASSED on a file that a standard YAML parser rejected. That is worth a look on its own — a validator accepting input its own ecosystem cannot parse is a real gap — but it is not the data-loss bug this issue describes, and it deserves its own report with a proper reproduction rather than living on inside a retracted one.

Apologies for the noise.

stack72 commented 8/23/2026, 9:43:21 PM

Thanks for the detailed report, @randybias.

We investigated both problems against the current codebase and were unable to reproduce either one. Here's what we tried:

Validate passing on broken YAML:

  • Created a workflow file with a truncated plain scalar and orphaned block text containing colons (matching your before/after snippets)
  • Ran swamp workflow validate — it correctly reported FAILED with bad indentation of a mapping entry
  • Tested with the orphaned text at different indentation levels (deeper, same as step keys, without blank line) — all variants were caught, either by the YAML parser or by unknown-key rejection
  • Confirmed the listBrokenWorkflows fix from #1896 is present in your reported version (sha.06b61472)

YAML rewrite in place:

  • Traced all code paths that write to source workflows/workflow-*.yaml files — only workflow create and workflow edit (stdin mode) call save() on the source repo
  • validate, evaluate, get, run, and vault are all read-only for source workflow files
  • Tested the @std/yaml stringify round-trip — it preserves block scalar (>-) formatting for multi-line strings, so save() alone wouldn't cause the truncation you described

Is this something you can consistently reproduce, or was it a one-time occurrence? If you can share one of the three broken files (or the exact sequence of commands from your shell history), that would help us pin down what's different between your environment and our reproduction attempts.

Sign in to post a ripple.