OpenAPI 3.1.0 Support null type - #2385
Conversation
Greptile SummaryThis PR adds initial OpenAPI 3.1 null type support in code generation. The main changes are:
Confidence Score: 3/5These issues should be fixed before merging.
pkg/codegen/schema.go and pkg/codegen/operations.go need follow-up around null nilability and enum handling. Important Files Changed
Reviews (1): Last reviewed commit: "handle null type" | Re-trigger Greptile |
Sorry, something went wrong.
| } else if t.Is("null") { | ||
| spec := globalState.typeMapping.Null.Resolve(f) | ||
| outSchema.GoType = spec.Type | ||
| outSchema.DefineViaAlias = true |
There was a problem hiding this comment.
Null enums break generation
This branch lets type: "null" schemas reach the enum/const generation path, but null enum values are later stringified as <nil> and emitted as unquoted Go constants. For an OpenAPI 3.1 schema with type: "null" and enum: [null] or const: null, the generated code contains an invalid assignment like a null enum constant set to <nil>, so the output does not compile. This path should either render a valid nil expression for the chosen representation or reject null enums before constants are emitted.
Sorry, something went wrong.
| if t.Is("null") { | ||
| return true | ||
| } |
There was a problem hiding this comment.
Mapped null may not be nilable
type-mapping.null is configurable, but this helper now treats every null schema as having a nil zero value. If a user maps null to a non-nilable Go type such as string, union and additional-properties marshal templates can emit checks like if t.Field != nil against that non-nilable field. The generated model code then fails to compile. This check needs to be based on the resolved Go type, or null mappings need to be constrained to nilable types.
Sorry, something went wrong.
| if t.Is("null") { | ||
| return true | ||
| } |
There was a problem hiding this comment.
Mapped null parameters break
The new null branch makes .RequiresNilCheck true for every null parameter, even though type-mapping.null can map null to a non-nilable Go type. With a mapping like null to string, client, webhook, and callback templates can generate if params.X != nil for a string parameter field. That generated code does not compile. Parameter nil checks should follow the resolved Go type instead of the OpenAPI type alone.
Sorry, something went wrong.
Per the OpenAPI 3.1.0 Spec:
Data types in the OAS are based on the types supported by the JSON Schema Specification Draft 2020-12. Note that integer as a type is also supported and is defined as a JSON number without a fraction or exponent part. Models are defined using the Schema Object, which is a superset of JSON Schema Specification Draft 2020-12.
The Schema Object allows the definition of input and output data types. These types can be objects, but also primitives and arrays. This object is a superset of the JSON Schema Specification Draft 2020-12.
On the feat/kin-openapi-3.1 branch, parsing the below spec fails.
oneOf: - type: object title: Player properties: id: type: string username: type: string rating: type: integer ratingDiff: type: integer required: - id - username - rating - type: object title: AI Opponent properties: id: type: "null" username: type: string ai: type: integer description: AI level, from 1 to 8, where 1 is the weakest and 8 is the strongest. required: - id - username - aiThis seems to be the same behavior described in #2336 (comment).
This PR aims to handle the null type with interface{}. I am not as familiar with the repo so perhaps implementation should be done in #2336.