fix: object unions drop data and select the wrong variant (#70)

[lightsofapollo]

Fixes #70, plus two further defects in the same family found while verifying it. Three commits, each independently reviewable.

1. An unconstrained object member of a type: [...] union dropped every key (#70)

Every member of type: [string, number, boolean, object, array, "null"] shares one SchemaDetails, so the object member can carry no object shape at all. It was still projected as a closed, empty struct:

pub struct GetEventResponsePayloadObject {}

{"payload":{"key":"value"}} deserialized without error and serialized back as {"payload":{}}.

Root cause. The single-type path already guards this — analyze_single_typed_schema's Object arm checks should_use_dynamic_json first. The typed-multi path had no equivalent, and couldn't reuse is_dynamic_object_pattern because that starts from schema_type(), which on a TypedMulti reports only the first non-null member (string, here), so the guard could never fire. The object-shape half is now split into object_shape_is_unconstrained(&SchemaDetails) and both callers use it.

An unconstrained member gets BTreeMap<String, serde_json::Value> — the shape this codebase already uses for an untyped map (UntypedShape::ValueMap). Crucially it matches only objects, so the untagged enum still routes arrays and scalars to their own members; serde_json::Value would swallow them. The generated type name is unchanged.

2. A type: object union branch claimed values belonging to later branches

p: { anyOf: [ {type: object}, {type: string} ] }

The object branch became pub type WVariant = serde_json::Value, which matches every JSON shape, so WP::String was unreachable for every input:

branch carrier	{"p": "hello"} deserializes to
serde_json::Value (before)	Some(WVariant(String("hello")))
BTreeMap<String, serde_json::Value> (after)	Some(String("hello"))

Applied at add_inline_union_branch_schema, the single choke point every union-branch path funnels through. Keyed on UntypedReason::OpaqueObject alone — a branch declaring no type ({}, true, {nullable: true}) genuinely admits any JSON and keeps serde_json::Value. That distinction is pinned as a negative case in the same spec as the positive one.

3. A closed struct in union-branch position swallowed keys the union could hold

The Microsoft Graph shape anyOf: [$ref User, {type: object, nullable: true}], with User stating additionalProperties: false and all-optional fields, still round-tripped {"user":{"free":"shape"}} as {"user":{}} after fixes 1 and 2. User matched any object, won the branch ahead of the map, and ate the key — even though the document forbids that key on User.

This required splitting a conflated model first. ObjectAdditionalProperties::Forbidden meant two different things:

what Forbidden meant	corpus object schemas	JSON Schema says
stated additionalProperties: false	7,157	closed
keyword omitted, projected closed	59,287	open

Keying strictness on Forbidden would have made 59k open objects reject keys the spec permits. Split into Denied (stated) and Closed (projected); the 16 read sites that only care whether a catch-all field exists now say so via is_open().

#[serde(deny_unknown_fields)] is emitted only when all three hold: the document stated it (Denied), the struct is reachable as an untagged union branch, and there is no flattened variant — serde rejects deny_unknown_fields alongside flatten at compile time. A closed struct outside any union has no branch to lose and stays tolerant, so generated clients keep working when a server adds a field.

Measured, not assumed

spec	structs	gained the attribute
anthropic	450	41 (9.1%)
cloudflare	11,425	34 (0.3%)
openai	1,244	6 (0.5%)
box	635	2 (0.3%)
asana	631	0
stripe	4,984	0
total	19,369	83 (0.4%)

Zero of 19,019 scanned generated struct blocks pair deny_unknown_fields with flatten, and anthropic's generated module — the highest concentration — compiles.

Verification

Three new test files, each pairing codegen assertions with a scratch crate that compiles the generated code and round-trips real JSON:

• unconstrained_object_union_member_test.rs — every member of the issue's union round-trips; shaped and additionalProperties: false members keep their structs.
• opaque_object_union_branch_test.rs — a string reaches String(_) past the object branch; a typeless branch stays serde_json::Value.
• closed_union_branch_strictness_test.rs — the attribute lands on exactly one of three structs; an undeclared key reaches the open branch and survives; a closed standalone struct still tolerates a newly added server field.

cargo test --all-features (686 tests, 0 failures), cargo clippy --all-features -- -D warnings, and cargo fmt --check are clean.

One pinned test changed behavior: recoverable_typing_test.rs::odata_nullable_reference_union_keeps_its_literal_object_branch. Its intent — don't collapse the union, keep a dynamic branch — is unchanged; only the carrier's spelling moves. I confirmed the explicit null that branch admits still hydrates before touching the assertion.

Deliberately not changed

• An omitted additionalProperties still drops undeclared keys on valid input ({"open":{"zzz":1}} → {"open":{}}). That is the generator's documented closed-model projection; preserving those keys means adding a flatten carrier to ~59k corpus schemas. A pre-existing tradeoff, not a regression.
• Discriminated-union variants do not gain deny_unknown_fields. They are selected by tag value, so branch laxness does not misroute them the same way.

🤖 Generated with Claude Code

https://claude.ai/code/session_012mBAVbYp2iUSL8VwpyDf19

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
openapi-to-rust	Ready	Preview	Sep 8, 2026 2:07pm UTC