Loading today’s stories
Build1 distinct publisher2 min readPublished
A dev.to writeup shows a chat client dying on event two of a longer model response. The transport was behaving; the parser assumed a guarantee SSE never makes.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The cheap part of the fix is one detail of the standard library. `json.JSONDecoder.raw_decode` parses a single JSON value from the start of a string and hands back the index where that value ended, without requiring the rest of the string to be valid JSON [8]. That is what lets a decoder work on a partial stream at all. The loop decodes at the current offset, keeps the object, advances past it, tries again in case two deltas arrived in the same chunk, and on a decode error stops and holds the unconsumed tail for the next call [9].
The defect is length-dependent, which is why it survives review. Nothing in a short-prompt test exercises a mid-object flush, and the server is entitled to flush mid-object because the protocol guarantees only framing: key/value lines, a blank-line terminator, and a `data` field carrying whatever bytes happened to be ready [5][6]. A suite of one-line answers stays green indefinitely.
Retrying does not reach the problem. The bytes on the wire were correct and the model completed its answer [4], so a second request runs the same decoder against the same flush behaviour and fails at the same point, one long prompt later. A retry cap is a policy about connections; the author's own list of drop-handling options, including asking the model to continue from partial text, which they call fragile and model-dependent and would not rely on [11], is about what to do with a stream that stops, not one that arrives in pieces.
Where the memory hazard actually sits is narrower than the article's warning suggests. Since the loop trims consumed bytes off the front and keeps only the remainder [9], a token-delta stream holds a fragment, not a transcript. The thing that bites is a single JSON value that never closes: the buffer grows, no decode ever succeeds, and nothing in the loop caps its size or times it out [9]. The caller also still owns end-of-stream detection, because the parser will happily hand back objects without noticing that `[DONE]` has arrived [14].
On provenance, the vendor's free tier is where the dropped-connection material lives [1][11], which is worth holding in mind when reading a free tier described as unreliable. The headline advertises JSON fragmented into 30 pieces [15]; the only trace shown splits one object across two events [7]. Two is the interesting number anyway, because two is where per-event `json.loads` stops working [16].
Ranked by verification strength, evidence, and original report placement.
The post's headline states that SSE fragmented the author's JSON into 30 pieces.
The author was building a streaming chat interface against MonkeyCode's free model access and its free server option.
The first few test runs worked because the server sent clean SSE events, each one a complete JSON object carrying a token of text, which the parser decoded one by one.
When the author asked for a longer response, the second event produced json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0).
The full response, captured to a file, was valid JSON; the model had not failed, and the parser had failed because it assumed each event contained a complete, self-contained JSON document.
Server-Sent Events is a framing protocol: each event is a set of key: value lines terminated by a blank line, and the data: field carries the payload.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Mechanism well demonstrated, magnitude unverified
The core technical claims are internally coherent and independently checkable in principle: SSE framing semantics are described correctly, the failure is shown with a quoted error and quoted fragments, and the fix is given as complete, runnable code with stated limits. But everything rests on one self-reported, vendor-disclosed post with no logs, counts, reproduction harness, or provider confirmation, and the headline figure is unsupported by the material shown.
No adoption signal in sources
The supplied source contains no release, deployment, benchmark, pricing, licensing, or usage-volume data. It reports one developer's personal build against a free tier, which does not establish adoption of MonkeyCode, of the parser pattern, or of any product in the cluster.
Headline inflates a two-fragment demo
The body's engineering content is measured and appropriately scoped -- it even tells readers the naive parser is fine when a provider guarantees one object per event. The overstatement sits in the packaging: a '30 pieces' headline with no count anywhere in the article, and a framing of a long-known streaming-client pitfall as a discovery, inside a piece disclosed as vendor product outreach.
Disclosed vendor outreach with free-to-paid framing
The article states outright that it was prepared as part of MonkeyCode's product outreach and is built on MonkeyCode's free model access and free server option, closing with advice that free tiers are less polished than paid tiers. The disclosure is explicit and to the author's credit, but the commercial interest in the subject matter is direct and shapes both the framing and the choice of failure narrative.
Low-moderate: verifiable mechanism, single interested source
Confidence is limited by structure rather than plausibility. One publisher, one self-reported incident, disclosed commercial interest, no corroboration and no adoption data mean the specifics cannot be confirmed; the general protocol claim and the published code are the parts a reader can check independently, which keeps this above the floor.
build
Your 90% Cache Hit Ratio Is a Lagging Indicator. Alert on Cold Misses Per Key1 distinct publisher
build
An AI test suite hit 94% coverage and missed the one branch that mattered1 distinct publisher
build
The dangerous cell in your state machine is the one nobody filled in1 distinct publisher
build
The model swap that cost three days: write the response contract before you pick a provider1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 25, 2026