Schema change for arrays has broken API compatibility

[harryjph]

Pull request #527, released in version v2.20.0, introduced a backwards-incompatible change to the way that Huma generates OpenAPI schemas.

Previously, arrays were recorded as an OpenAPI array type, but now they are recorded as either array or null. This change was pushed out in a minor version update, which the go tool will often quietly upgrade to. By upgrading to this version, any application using Huma has subtly made a breaking change to its API schema.

Adding additional types to the schema means that clients generated from the schema now have to add logic to deal with both possibilities. I know that Go can serialise arrays as null, but our application is written in a way such that this is not possible.

This also totally breaks oapi-codegen:

$ oapi-codegen -generate "types,client" -package {package} openapi.json
error generating code: error generating type definitions: error generating Go types for component schemas: error converting Schema {type} to Go type: error generating Go schema for property '{property}': error resolving primitive type: unhandled Schema type: &[string null]

There are multiple other people reporting this issue on the original PR thread.

Please make the change to how schemas are generated a configurable option.

[harryjph]

Update: I have found that the OpenAPI 3.0 (as opposed to 3.1) schema is not affected by this change, so oapi-codegen users should use the openapi-3.0.json schema. Closing for now.