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 json in new[]{"{\"id\":1,\"name\":\"rune\",\"optional\":\"new\"}","{\"id\":1,\"name\":42}"}) { using var doc=JsonDocument.Parse(json); var root=doc.RootElement; Console.WriteLine(root.TryGetProperty("name",out var name)&&name.ValueKind==JsonValueKind.String?"compatible":"rejected"); }
int committed=0; bool failBefore=true; if(!failBefore)committed++; Console.WriteLine("before:"+committed); committed++; Console.WriteLine("after:"+committed);
Reveal answer and reasoning
The output lines, in order, are “compatible”; “rejected”; “before:0”; “after:1”. The portable .NET9 console program parses two fixed JSON strings with JsonDocument and checks whether name exists with string kind. The extra optional property in the first body does not affect that check, so it prints compatible. The second name is numeric and prints rejected. Its later integer model leaves committed at zero for a pre-commit failure and increments it before the after line, producing before:0 and after:1.
This companion does not validate every rule of the external consumer: the real Accept method additionally checks a positive integer id and a nonblank name. It also opens no HTTP connection or SQL transaction.
Ignoring unknown properties can be compatible for this tolerant consumer without making every added field harmless for every client. Required property names, kinds, ranges and nullability still matter. JsonDocument parsing proves syntactic JSON, while Accept supplies the narrower application contract. Likewise, a failed response does not prove the server failed before applying a mutation. Repeating the after endpoint would increment again because this endpoint intentionally has no request-receipt protocol.
The verifier also requires a fresh fixture, so old contract_effect state must not be mistaken for a failure of its zero baseline or used to claim a clean independent run.
What a strong answer covers
- Exact output: compatible | rejected | before:0 | after:1
- The portable .NET9 console program parses two fixed JSON strings with JsonDocument and checks whether name exists with string kind.
- Ignoring unknown properties can be compatible for this tolerant consumer without making every added field harmless for every client.
Common pitfall
Ignoring unknown properties can be compatible for this tolerant consumer without making every added field harmless for every client. Required property names, kinds, ranges and nullability still matter. JsonDocument parsing proves syntactic JSON, while Accept supplies the narrower application contract. Likewise, a failed response does not prove the server failed before applying a mutation. Repeating the after endpoint would increment again because this endpoint intentionally has no request-receipt protocol. The verifier also requires a fresh fixture, so old contract_effect state must not be mistaken for a failure of its zero baseline or used to claim a clean independent run.
Follow-up questions
- Which invalid bodies can the external Accept predicate reject even though the portable name-kind check would accept them?
- Why is a changed JSON property kind a compatibility failure even when transport status remains200?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.