fix: handle empty schemas as "any" type instead of error#1585
Merged
ernado merged 3 commits intoogen-go:mainfrom Nov 25, 2025
Merged
fix: handle empty schemas as "any" type instead of error#1585ernado merged 3 commits intoogen-go:mainfrom
ernado merged 3 commits intoogen-go:mainfrom
Conversation
Empty schemas (nil schema in OpenAPI specs) represent "any valid JSON value"
according to JSON Schema specification. Previously these were treated as
errors, but they should be handled as ir.Any (jx.Raw in Go).
This commonly occurs in request/response bodies with content but no schema:
{"content": {"application/json": {}}}
Changes:
- Modified schema_gen.go to return ir.Any(nil) for nil schemas
- Added documentation explaining empty schema semantics
- Aligned with existing array handling (line 431)
- Added regression test TestSchemaGenNilSchema
- Moved response_content_schema.json from negative to positive testdata
Fixes #10
Empty schemas (missing schema field in OpenAPI media type objects) now have context-aware handling: **Responses**: Generate jx.Raw (any JSON value) - Allows clients to handle unknown JSON structures from servers - Solves issue #10 for default error responses and flexible APIs - Consistent with JSON Schema spec (empty schema = any JSON) **Requests**: Return error "empty schema in request body" - Prevents clients from sending arbitrary data without spec guidance - More conservative approach - requires explicit schema or ignore flag - Avoids over-permissive APIs where spec doesn't define structure Changes: - Added `request bool` field to `generateSchemaOverride` and `schemaGen` - Modified `generate2()` to check context before handling nil schemas - Updated `generateContents()` to pass request flag via override - Split test into separate Response/Request test cases - Updated test data to use response-only empty schema test Fixes #10
ernado
approved these changes
Nov 25, 2025
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.
Summary
Implements context-aware handling for empty media type objects in OpenAPI specs. Responses with missing schemas generate
jx.Raw(flexible), requests with missing schemas error (conservative).Fixes #10
The Rule
Following Postel's Law: be liberal in what you accept, conservative in what you send.
Why This Approach?
Missing schema ≠ "accepts anything" (per OpenAPI spec maintainer)
jx.Rawto handle varying/unknown structures (errors, legacy APIs, vendor-specific fields)Users wanting arbitrary request bodies should explicitly specify
schema: true(JSON Schema's "any" type) rather than omit the schema field.Examples
Response (works):
Request (errors):
Testing
Guarantees:
jx.Rawreturn typesImpact
Unblocks code generation for real-world APIs (default error responses, flexible endpoints, legacy specs) while preventing unspecified client behavior.