Production engineering
using System;
using System.Linq;
using System.Collections.Generic;
using System.Globalization;
using System.Text;
using System.Text.Json;
using System.Threading;
using System.Threading.Tasks;
foreach(string[] records in new[]{new[]{"item:1","item:2","complete:2"},new[]{"item:1","error"}}) { int count=records.Count(x=>x.StartsWith("item:",StringComparison.Ordinal)); Console.WriteLine(records.LastOrDefault()=="complete:"+count&&count==2?"accepted:"+count:"incomplete"); }
Reveal answer and reasoning
The output lines, in order, are “accepted:2”; “incomplete”. The portable .NET9 console program examines two fixed arrays of markers. It counts strings beginning with item: using ordinal comparison, then checks that the last marker equals complete plus the counted value and that the count is exactly two. The first array has two items and complete:2, so it prints accepted:2. The second contains one item and error, so it prints incomplete.
This is deterministic publication policy over known markers. It does not deserialize arbitrary NDJSON, verify sequence identifiers, enforce byte limits or open a socket. Even a successful marker check would need a stronger parser before accepting hostile external records.
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.
What a strong answer covers
- Exact output: accepted:2 | incomplete
- The portable .NET9 console program examines two fixed arrays of markers.
- 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.