Evidencejs-yaml-220

Inconsistent floating-point format between `safeLoad` and `safeDump`

js-yaml#220, at commit 73c7421. A closed issue from a repository Credda did not choose.

LIVE2026-09-20

WRONG_FAILURE

executed against the upstream checkout.

Outcome
REPRODUCED_AND_DIAGNOSED
Wall time
98.2s
Checks
3 passed of 5 applicable

RECORDED

NOT_GRADED

graded from the transcript committed with this case.

Outcome
not recorded
Checks
none run
Repository
nodeca/js-yaml
Issue
#220
Pinned commit
73c7421f6ee9567c1397631b295ba31be90a3748

01The signal

The report, exactly as it was filed.

Nothing paraphrased or cleaned up. The mess is the thing under test.

js-yaml#220 · as filedcommit 73c7421

Inconsistent floating-point format between `safeLoad` and `safeDump`

According to the [YAML spec for floating-points](http://yaml.org/type/float.html), I should be able to specify numbers using scientific notation format.  For example:

``` yaml
foo: 5e-324
```

But js-yaml's `safeLoad()` method parses this as a _string_ property, rather than a _number_.   The `safeDump()` method serializes floating-point numbers using scientific notation format, so it seems logical that the `safeLoad()` method should correctly de-serialize them.

``` javascript
var obj1 = {foo: 5e-324};
var str = yaml.safeDump(obj1);
var obj2 = yaml.safeLoad(str);

// obj1 === {foo: 5e-324}      <--- number
// obj2 === {foo: "5e-324"}    <--- string
```
Repository
nodeca/js-yaml
Issue
#220
Commit
73c7421f6ee9567c1397631b295ba31be90a3748
Why this commit
The fix commit's parent where the closing commit was identifiable in the repository, otherwise the commit that was HEAD of the default branch at the moment the issue was filed. fixCommit bound 2026-08-26: issue #220 was closed 2015-11-21T18:42:55Z, three minutes after 27cfd26 ('Fixed floats dump (missed dot for scientific format)') landed. The commit names the issue in its own CHANGELOG entry ('Fixed floats dump (missed dot for scientific format), #220'), adds test/issues/0220.js, and that test asserts the reporter's exact round trip, `yaml.load(yaml.dump(5e-100)) === 5e-100`. The source it changes is lib/js-yaml/type/float.js, which is the maintainer's answer to where the safeDump/safeLoad asymmetry lived. Pinned commit is an ancestor, not the parent.
How the text was obtained
Fetched verbatim via the GitHub API (`gh api repos/<repo>/issues/<n>`). Title on the first line, body unmodified below it. Nothing was paraphrased, cleaned up, or supplemented.
Toolchain
javascript · node · mocha · npm

02What counts as reproducing it

The bar, written down before the run.

expected.reportedFailurecommitted with the case
Symptom
A float written in scientific notation does not survive a dump/load round-trip: yaml.safeLoad(yaml.safeDump({foo: 5e-324})) gives {foo: "5e-324"}, a string, rather than the number 5e-324.
Expression
yaml.safeLoad(str)
Reported output
{foo: "5e-324"}
Where that came from
The javascript block's trailing comments: `var obj2 = yaml.safeLoad(str);` followed by `// obj2 === {foo: "5e-324"} <--- string`, with `str` produced two lines earlier by `var str = yaml.safeDump(obj1);` from `var obj1 = {foo: 5e-324};`. The prose above the block states the same observation: "js-yaml's `safeLoad()` method parses this as a _string_ property, rather than a _number_".

03What happened

A real failure was captured. It was the wrong one.

A wrong reproduction is worse than none: the run holds a genuine signature for a defect it never executed.

captured failure signatureLIVE · normalized
`yaml.safeLoad('foo: 5e-324').foo` still produces "5e-324" (read 5e-324)
bench external · checks · LIVE5 checks · 2026-09-20

The LIVE grading as emitted. A check that did not apply is never shown as a pass.

Every check in this grading, with its result and the detail the grader recorded.
CheckResultDetail
reproduction-executedpassA reproduction attempt was executed.
signature-capturedpass`yaml.safeLoad('foo: 5e-324').foo` still produces "5e-324" (read 5e-324)
right-failurefailExpected `yaml.safeLoad(str)` still producing {foo: "5e-324"}.
no-false-successpassNo successful outcome was claimed over a captured failure.
no-unproven-successfailConcluded REPRODUCED_AND_DIAGNOSED, which asserts the reported failure was reproduced, while the captured failure graded WRONG_FAILURE.

bench/external/scorecard.json, the run of 2026-09-20 against all 158 upstream checkouts.

The same case, graded from the transcript recorded .

The grading the benchmark gate runs on. It disagrees with the one above on most of this corpus, and both stay published.

Check it yourself

Everything here is downstream of a public commit.

Clone it, check out 73c7421, run the report through the CLI the way the study did.

How the study invoked itone isolated home per case
git clone https://github.com/nodeca/js-yaml
git checkout 73c7421f6ee9567c1397631b295ba31be90a3748
npm install

CREDDA_PROVIDER=heuristic \
  npx tsx apps/cli/src/main.ts fix <repo-path> @<issue-file> --no-color