Single-quoted multi-line flow scalar ending with a blank line loses indentation level on output

[taisph]

Describe the bug
When the source YAML below is run through yq . it ends up with the last single-quote at the wrong/unexpected indentation level.

Version of yq: 4.53.2 4.53.3
Operating system: Ubuntu Linux
Installed via: mise

Input Yaml
Concise yaml document(s) (as simple as possible to show the bug, please keep it to 10 lines or less)
source.yml:

paths:
  /v1/quack:
    get:
      description: '
        Get quacked.

        - Duck

        '

Command
The command you ran:

yq . source.yml

Actual behaviour

paths:
  /v1/quack:
    get:
      description: ' Get quacked.

        - Duck

'

Expected behaviour

paths:
  /v1/quack:
    get:
      description: '
        Get quacked.

        - Duck

        '

Additional context
Oddly, yq treats the output as valid and parsable even though some other tools flag is as incorrect. Also, using double-quoting does not exhibit this behaviour.

[1816586742-stack]

Generated by an AI agent (Claude) acting on the user's behalf, not the user personally.
The agent ran the commands below and pasted their real output; the human reviewed it
before posting.

---

Three things measured against yq built from ef305ad (master), plus one check that rules
out the obvious fix. None of this changes the report, it narrows it.

1. The value is not corrupted

The rendered block is reflowed, but the scalar it represents is identical. Reading the
value back out as JSON, from the original, from yq's own output, and from the "expected"
layout in the report:

$ yq -o=json -I=0 '.paths."/v1/quack".get.description' source.yml
" Get quacked.\n- Duck\n"

$ yq . source.yml > once.yml
$ yq -o=json -I=0 '.paths."/v1/quack".get.description' once.yml
" Get quacked.\n- Duck\n"

# the layout from the "Expected behaviour" section, saved as a file
$ yq -o=json -I=0 '.paths."/v1/quack".get.description' expected.yml
" Get quacked.\n- Duck\n"

and a second opinion from a different parser:

$ python -c "import yaml,json;print(json.dumps(yaml.safe_load(open('source.yml'))['paths']['/v1/quack']['get']['description']))"
" Get quacked.\n- Duck\n"
$ python -c "import yaml,json;print(json.dumps(yaml.safe_load(open('once.yml'))['paths']['/v1/quack']['get']['description']))"
" Get quacked.\n- Duck\n"

So all three layouts denote the same string - " Get quacked.\n- Duck\n", with a leading
space, which is what the report's own "Actual behaviour" block shows too (' Get quacked.).
The difference is representation, not data. It is also stable: a second yq . over the
output produces byte-identical output, so this is not something that drifts on each pass.

The YAML also states it plainly: in a single-quoted scalar a line break folds to a space
and a blank line folds to a newline, and the content lines here sit at the same indentation
as the opening quote, so those are folding spaces and each is a real space in the value.
Both layouts lose the block structure and agree on the result.

2. The pending upstream bump does not fix it

The most likely fix for a scalar-emission reflow is the yaml library itself, so I applied
the bump from #2873 to a throwaway tree and rebuilt:

$ go get go.yaml.in/yaml/v4@v4.0.0-rc.6.0.20260808141834-8edd87069cbe
go: upgraded go.yaml.in/yaml/v4 v4.0.0-rc.6 => v4.0.0-rc.6.0.20260808141834-8edd87069cbe
$ go build -o yq-bump .

$ ./yq-bump . source.yml
paths:
  /v1/quack:
    get:
      description: ' Get quacked.

        - Duck

'

Identical to before, and the value still reads back as " Get quacked.\n- Duck\n". So this
one is not waiting on #2873 and is not fixed by it.

3. What that leaves

The honest categorisation is: yq re-emits a single-quoted scalar across multiple lines with
its own line-wrapping, and that wrapping is not round-trip faithful for the layout. It does
not change the document's meaning, and the output parses as valid YAML in both the library
yq uses and a second parser, but yq . is expected to be a near-identity on a document it
has no reason to restyle, and this one visibly is not.

Given that, a fix is a scalar-rendering change rather than a bug in value handling: either
keep the source layout for a multi-line quoted scalar (what the report expects), or at
least indent the continuation lines so the output does not read as if the opening quote
swallowed a word. I am not proposing a patch here because "keep the source layout" and
"re-wrap consistently" are different behaviours with different diffs, and the choice is the
maintainer's - happy to write either one against a decision.