Target: sveltejs/kit
Issue: sveltejs/kit#15511
Pull request: sveltejs/kit#16423
Result: upstream accepted and merged
Field Lab record: SvelteKit #15511
This field test started with a rare __data.json corruption issue in SvelteKit.
The visible symptom was intermittent JSON.parse failure during page invalidation, often around streamed promises and slower network conditions. The reporter said the issue had been difficult to reproduce.
That made it a good diagnostic challenge.
The important clue was not just that JSON parsing failed.
It was the replacement character � appearing inside what should have been valid JSON.
That changed the shape of the problem.
The boundary
The streamed data path looked like this:
raw bytes -> UTF-8 text -> NDJSON record -> JSON.parse
The visible crash happened at JSON.parse.
But the useful repair boundary was earlier:
raw bytes -> UTF-8 text
The � character suggested that malformed UTF-8 bytes were being decoded with replacement behavior before parsing. By the time JSON.parse failed, the data had already become corrupted text.
So the question was not:
“Why did JSON.parse fail?”
It was:
“Why did corrupted text reach JSON.parse at all?”
That is the kind of distinction Scarab is built to surface.
What changed
The patch updated the streamed NDJSON reader so malformed UTF-8 fails during decoding instead of being allowed to become corrupted JSON text.
The generic stream reader remains reusable by allowing TextDecoderOptions.
read_ndjson now uses fatal UTF-8 decoding.
Regression coverage was added for both sides of the boundary:
- valid UTF-8 split across chunks still parses correctly;
- malformed UTF-8 rejects before JSON parsing.
That is the whole repair.
No JSON parser rewrite.
No broad streaming redesign.
No claim to reproduce every timing condition.
Just a narrower contract:
invalid bytes should not become JSON text.
Why this matters
Rare bugs do not always give you a clean reproduction.
Sometimes they give you a boundary.
If the only question is “where did the exception appear?”, the answer is JSON.parse.
But that was not where the system first lost integrity.
The repair was not at the crash site.
The repair was at the boundary that should have prevented the crash site from receiving corrupted data in the first place.
That is the difference between patching symptoms and restoring coherence.
Merged update
This PR has now been accepted upstream.
sveltejs/kit#16423 was merged into version-3 by Rich Harris on July 19, 2026.
The PR title was:
fix: reject malformed streamed data encoding
The maintainer added a changeset commit before merge, and the review decision was approved.
This field report claims upstream acceptance of the repair PR.
It does not claim release inclusion yet. Release inclusion is a separate proof surface and should be recorded only if the change is carried into a published SvelteKit package version or prerelease.
Field test result
Result:
diagnostic proof and repair accepted upstream.
This field test produced:
- a public issue-to-boundary record;
- a narrow streamed-data encoding repair;
- regression coverage for the byte-to-text boundary;
- a public upstream PR;
- maintainer review;
- upstream merge into
version-3.
The patch was deliberately narrow.
That is the point.
The visible failure was JSON.
The broken boundary was bytes becoming text.
Scarab diagnosed the boundary.
Codex implemented the repair.
SvelteKit accepted the change.
Public claim
This field test supports one narrow claim:
SDS identified a streamed-data encoding boundary in SvelteKit where malformed UTF-8 could become corrupted JSON text before parsing, and a human-submitted repair was accepted upstream to reject malformed streamed data during decoding.
It does not claim that the full rare network/timing condition was reproduced end to end, that every possible __data.json corruption path is fixed, that the patch has shipped in a public SvelteKit release, or that SvelteKit maintainers endorsed Scarab.
The Field Lab exists to keep those claims separate.
Disclosure
This field report was prepared with AI-assisted editing from public field-test notes, public issue and PR records, and the public Field Lab record. The diagnostic claim, repair boundary, and final wording were human reviewed.
Scarab Diagnostic Suite is proprietary. The Field Lab publishes public case records, issue links, validation summaries, and claim boundaries only.
SDS finds evidence. People make claims. Maintainers decide.
Top comments (0)