Production engineering
Reveal answer and reasoning
Streaming moves some output across the network before the complete application result exists. A successful initial status therefore cannot certify that all intended records were produced or accepted. This fixture defines its own NDJSON protocol: two item records followed by a terminal complete record whose count is two. A controlled failure emits an error record without complete, while an abort can terminate the connection after a prefix.
The completion marker is an application contract layered over HTTP, not a built-in transaction or a property that every newline-delimited stream automatically has. Consumers must choose when partial data becomes visible to their own callers.
In HttpLabs.cs, /stream sets application/x-ndjson and serializes each item to the actual response. Each item is followed by a newline and a body flush, allowing the client to observe a prefix before the operation finishes. fail=true returns an error record after the first item and stops; abortAfter=1 calls context.Abort instead. The normal path writes the complete record after both items.
WriteAsync and FlushAsync receive RequestAborted, so disconnects can interrupt server work. Once the response has started, a later problem cannot simply replace the already transmitted status and body with a new ordinary error response.
What a strong answer covers
- Streaming moves some output across the network before the complete application result exists.
- In HttpLabs.cs, /stream sets application/x-ndjson and serializes each item to the actual response.
- A flushed server write does not prove that every byte reached the client or that a downstream consumer committed it.
Common pitfall
A flushed server write does not prove that every byte reached the client or that a downstream consumer committed it. An aborted response may expose a partial prefix, raise a transport exception or do both at different layers. Error records also require a specified schema and ordering policy; their mere presence does not roll back an external effect already performed per item. This classroom endpoint does not implement per-record size limits, a total byte budget or a resumable cursor. Its two fixed items bound the fixture, while a generalized streaming API needs explicit resource and recovery rules.
Follow-up questions
- How would a resumed stream identify already applied records without turning a partial prefix into an automatic duplicate effect?
- What additional validation would a real NDJSON parser need beyond the portable item-prefix and last-marker check?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.