Skip to main content
← Back to list
01Issue
BugOpenSwamp CLIPublic
AssigneesNone

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○SHIPPED

Open

8/22/2026, 7:38:42 PM

No activity in this phase yet.

03Sludge Pulse
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.

Sign in to post a ripple.