Fix v2.6.0 omitempty regression - #2505
Merged
mromaszewicz merged 1 commit intoJul 31, 2026
Merged
Conversation
Copy link
Copy Markdown
Member
Sorry, something went wrong.
Fixes oapi-codegen#2503 Since v2.6.0, nullable struct fields received an `omitempty` JSON tag, changing the wire format for unchanged specs: required+nullable fields lost their always-present key (a JSON Schema `required` violation when the pointer is nil), and optional+nullable fields could no longer emit an explicit `null`, collapsing the null-vs-absent distinction that `nullable: true` exists to express. The guard was removed by d567e49 (oapi-codegen#2221), which aligned the code with an inaccurate README example that issue oapi-codegen#2091 had taken as the documented behavior. Restore the pre-2.6.0 rule in GenFieldsFromProperties: nullable fields never get `omitempty`, except under the `nullable-type` output option, where nullable.Nullable[T] models absent-vs-null itself and relies on `omitempty` for the absent case. The rule applies uniformly to OpenAPI 3.0 `nullable: true` and the 3.1 `type: [..., "null"]` / null-branch idioms, since Property.Nullable covers both. Also revert the test expectations flipped by d567e49, update the two nullable round-trip tests that had baked in the regressed behavior (nil nullable fields now marshal as explicit nulls, identically across spec versions), regenerate the affected fixtures, and correct the README example that showed `omitempty` as the default for nullable fields. Users who prefer omission for nullable fields can opt in explicitly via `x-omitempty: true` or the `nullable-type` output option. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Copy link
Copy Markdown
Contributor
Greptile SummaryRestores explicit-null serialization for nullable fields generated without nullable-type.
Confidence Score: 4/5This needs a fix before merging because required nullable readOnly and writeOnly fields can now be serialized on the schema direction where they must be absent. The nullable guard discards the existing omitempty decision for directional fields, causing nil readOnly fields to appear in requests and nil writeOnly fields to appear in responses as explicit nulls. Files Needing Attention: pkg/codegen/schema.go Important Files Changed
### Issue 1
pkg/codegen/schema.go:1445
**Preserve directional field omission**
When a required nullable property is marked `readOnly` or `writeOnly`, this condition overrides the existing directional `shouldOmitEmpty` decision, causing nil read-only fields to be emitted as `null` in requests and nil write-only fields to be emitted as `null` in responses where the schema requires them to be absent.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "Fix v2.6.0 omitempty regression" | Re-trigger Greptile |
Sorry, something went wrong.
Comment thread
pkg/codegen/schema.go
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.
Fixes #2503
Since v2.6.0, nullable struct fields received an omitempty JSON tag, changing the wire format for unchanged specs: required+nullable fields lost their always-present key (a JSON Schema required violation when the pointer is nil), and optional+nullable fields could no longer emit an explicit null, collapsing the null-vs-absent distinction that nullable: true exists to express. The guard was removed by d567e49 (#2221), which aligned the code with an inaccurate README example that issue #2091 had taken as the documented behavior.
Restore the pre-2.6.0 rule in GenFieldsFromProperties: nullable fields never get omitempty, except under the nullable-type output option, where nullable.Nullable[T] models absent-vs-null itself and relies on omitempty for the absent case. The rule applies uniformly to OpenAPI 3.0 nullable: true and the 3.1 type: [..., "null"] / null-branch idioms, since Property.Nullable covers both.
Also revert the test expectations flipped by d567e49, update the two nullable round-trip tests that had baked in the regressed behavior (nil nullable fields now marshal as explicit nulls, identically across spec versions), regenerate the affected fixtures, and correct the README example that showed omitempty as the default for nullable fields.
Users who prefer omission for nullable fields can opt in explicitly via x-omitempty: true or the nullable-type output option.