OpenAPI 3.1.0 Support null type#2385
Conversation
Greptile SummaryThis PR adds initial OpenAPI 3.1
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.
|
| Filename | Overview |
|---|---|
| pkg/codegen/schema.go | Adds null primitive conversion and model nil-check behavior; null enum and custom-mapping cases need fixes. |
| pkg/codegen/operations.go | Adds null parameter nil-check behavior; custom null mappings can make generated parameter code fail to compile. |
| pkg/codegen/typemapping.go | Adds a default and user-overridable mapping entry for OpenAPI null. |
Reviews (1): Last reviewed commit: "handle null type" | Re-trigger Greptile
| } 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.
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.
| if t.Is("null") { | ||
| return true | ||
| } |
There was a problem hiding this comment.
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.
| if t.Is("null") { | ||
| return true | ||
| } |
There was a problem hiding this comment.
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.
acd9443 to
f8a51bc
Compare
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.
This 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.