1.9 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| resolved | 2026-08-31 |
|
mesh-host — something after the declaration is refused whole |
016 — Anything after the declaration in a file was ignored
Symptom
A JSON decoder reads one value and stops. The host's declaration parser used one, so a file holding a declaration followed by anything at all — a stray line, a second declaration, the tail of a truncated rewrite — parsed as the first value and the rest was never looked at.
The machine applied something, reported success, and what it applied was not what the file said.
Why this matters
The host refuses a partial declaration everywhere else, in these words: a host that applied the parts it understood would leave a machine that looks configured and is not. This was the same fault in its quietest form — not a part left out, but a part never seen, with nothing anywhere saying so.
It was live and invisible. The end-to-end harness had been appending a line to the substrate bundle by accident (015), and every bootstrap in every run applied a bundle with a junk line on the end. Nothing failed, so nothing was looked at, and the corruption was found only by tracing a different bug backwards.
That is the argument for refusing rather than tolerating. A file with something after it is more likely to be damaged than deliberate: an interrupted write, two files concatenated, a generator that emitted twice. Applying the first value is applying something nobody wrote.
What was done
After decoding, the parser requires end of input. Trailing whitespace is not "something after it" — refusing that would make every file an editor writes unusable.
Checked by a valid declaration with a stray line after it, with a second declaration after it, and with garbage after it, each refused; and by the same declaration with trailing blank lines, accepted.