Response records are nullable where the protocol never says they can be

[Agash]

The friction

Every read of a response goes through a ! or a ?.:

string[] names = (await client.Scenes.GetSceneListAsync(new(), ct)).Scenes!.Select(s => s.SceneName!).ToArray();
int count = (await client.Scenes.GetSceneListAsync(new(), ct)).Scenes?.Count ?? 0;

The example project alone carries 73 of these on response reads. The request itself is already non-nullable, since CallRequiredAsync throws rather than handing back null, so the remaining noise is entirely inside the records.

Where it comes from

All 152 response fields in protocol.json have valueOptional: null. The protocol never marks a response field optional; it only does that for request fields. So the generator has no signal, and its current rule keys off the C# type rather than the definition:

	count	share
response properties	152
generated nullable	88	57%
generated required	64	42%

Value types became required and non-nullable; reference types became nullable. That split follows from C#, not from OBS. GetSceneList always returns scenes, and GetVersion always returns obsVersion, but both are typed as though they might not.

What to consider

Making reference-typed response fields non-nullable and required would delete the ! from ordinary code. The cost is that required makes System.Text.Json throw when the field is absent, so a response OBS trims, or an older OBS that predates a field, would fail the whole read rather than yield a null.

That risk is not hypothetical in one direction: the 64 already-required value fields have exactly that behaviour today and have not caused trouble, which is some evidence the protocol's response shape is honoured in practice. It is also why the payload shape check was written as a key-overlap test rather than a required-field test.

Options, roughly in increasing boldness:

1. Leave it and document the !.
2. Make fields non-nullable only where the field is documented without an "optional" or "null if" phrase in valueDescription. Several say things like "null if not playing", which is exactly the set that must stay nullable. This is derivable from the definition rather than hand listed.
3. Make every reference-typed response field non-nullable, and accept that a missing field throws.

Option 2 looks like the honest one: the prose is the only place the protocol records nullability for responses, and it is already the signal used to fix GetMediaInputStatus, which failed to deserialize whenever media was not playing because a field documented as nullable in prose had been generated non-nullable.

Scope note

This changes the shape of every response record, so it belongs in one release with the other breaking work rather than trickling out.

[Agash]

Implemented in #21.

What the research turned up

The prose is a complete signal. 12 of 84 reference-typed response fields document a null, and every one is a real case (null if not playing, null if not in studio mode, else null). Scanning the rest for absence phrasing that avoids the word null (optional, if any, only when, omitted, may be, unset, otherwise) returned 0 matches, so there is nothing the word-null test misses.

Older OBS is not a risk, which was the main worry. Comparing each field's initialVersion against its parent request or event: no field has ever been added to a request or event that already existed. All 21 post-5.0.0 response and event fields belong to a request or event introduced at that same version. So an older OBS never sends a partial payload for a request it supports; it rejects the request instead. Option 3 would have been safe too, but option 2 is what landed since it costs nothing extra.

Result

	before	after
response properties nullable	57%	16%
event properties nullable	~62%	7%

Everything still nullable is either documented as null (16) or an Object/Any settings blob (9), where JsonElement? distinguishes "OBS did not send it" from "OBS sent {}" and a non-nullable JsonElement would collapse both into ValueKind.Undefined.

The stubs, which the issue did not cover

SceneStub, SceneItemStub, SceneItemTransformStub and the rest are hand written, and the protocol has no nested field definitions at all, so there was nothing to derive from. They were checked against the payloads a live OBS 32.2.2 returns instead. That found two things guessing would have got wrong:

• isGroup really is null for a non-group scene item, so it stays nullable.
• cropLeft/Top/Right/Bottom, alignment, boundsAlignment, sceneItemId, sceneItemIndex, sceneIndex, monitorIndex and inputKindCaps arrive as integers, not floats, so they are int now rather than double. The geometry (positionX, scaleX, width, rotation) is genuinely fractional and stays double.

Side effect worth recording

MessagePack does enforce required members: it reports missing required properties and throws. The earlier finding on #16 that MessagePack silently accepts a wrong payload only held for records with no required member to miss. With this change both transports reject a payload missing required fields, which is the strictness parity that was wanted.

Validated against OBS 32.2.2 on both transports, 81 checks each, plus 254 unit tests.