fix: unions used as a request or response body generate typed instead of any - #36
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
A
oneOf/anyOfschema used directly as a request or response body generatedany. It now generates the same typed union the generator already produces elsewhere.The synthesis path existed and worked; it was simply never reached from bodies.
synthesizeInlineUnionreturns false without a naming hint, and the body path resolved with an empty one:This threads the operation's Go name down through
convertRequestBody,convertResponses,convertSingleResponse, andresolveMediaTypeSchema, so a body union is named<Operation>Bodyor<Operation>Response.Titled unions name themselves
Synthesized unions are deduplicated by variant refs and discriminator, so a union shared by several operations is named after whichever one the spec reaches first. That is order-dependent: inserting a route earlier renames existing generated types, which is churn for consumers that diff-gate their SDK.
So a
titleon the union now wins over the operation hint. A spec that names its unions gets stable names regardless of route order; a spec that does not still improves fromany.Effect on a real spec
Against the Parallel Works API (754 types), before:
after, with
titleset on the two attached-storage unions and nothing else changed:The generated union carries the discriminator-driven
UnmarshalJSON, so decoding yields the concrete variant rather than a map.Tests
testdata/complex-schemas.yamlgains two paths: one with untitled union bodies, one titled. New tests assert the untitled bodies take the operation hint, that an identical union elsewhere still deduplicates, and that a titled union uses its title and does not also emit a hint-named type. The exact-count assertion inTestComplexSchemas_AllTypesPresentis updated for the three new synthesized types.Note this changes generated output for any spec with union bodies: those signatures move from
anyto a named type. That is the point, but it is a visible diff for consumers on regeneration.