OpenAPITools / OpenAPITools/openapi-generator
[BUG][JAVA] Generated Lists default to empty List even when using nullable: true and containerDefaultToNull: true
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
Bug Report Checklist
- Have you provided a full/minimal spec to reproduce the issue?
- Have you validated the input using an OpenAPI validator (example)?
- Have you tested with the latest master to confirm the issue still exists?
- Have you searched for related issues/PRs?
- What's the actual output vs expected output?
- [Optional] Sponsorship to speed up the bug fix or feature request (example)
Description
Generated Lists default to empty List even when using nullable: true and containerDefaultToNull: true
We need to allow the end user to not pass a certain non-required list query param and recognize it as null, because we need to distinguish it from when they pass us an empty list -> it means semantically something else than when they do not pass anything, pass null as the query param. The containerDefaultToNull was supposed to affect this, but setting that property leads to exactly same generated code base. Adding nullable: true also doesn't help, as was suggested elsewhere to use.
openapi-generator version
6.5, 7.1, latest docker image, assuming that's 8.0
OpenAPI declaration file content or url
openapi: 3.0.0
info:
title: Simple API
version: 1.0.0
paths:
/your-endpoint:
get:
summary: Endpoint that accepts a list of strings as a query parameter
parameters:
- name: items
in: query
description: A list of strings
required: false
schema:
type: array
nullable: true
items:
type: string
responses:
'200':
description: Successful response
Generation Details
openapi-generator generate -g java -i open/openapi.yaml -o open2 -c /tmp/config.json
config has only
{
"containerDefaultToNull":true
}
and you can actually leave it out and compare what's generated and you'll see you get exactly the same code base, which points to the fact, that the parameter is completely ignored.
Steps to reproduce
- Use the generator as above with the specified spec above
- Do the same but with the configuration above used
- Observe that there is no difference in codebase. Calling the endpoint without the query param will result in an empty list for the query param on the server code.
Related issues/PRs
This looks similar, but says the other way around -> that it no longer defaults to list but to null. I have the opposite experience. https://github.com/OpenAPITools/openapi-generator/issues/15891 My comment there about this issue is: https://github.com/OpenAPITools/openapi-generator/issues/15891#issuecomment-1824662849
Suggest a fix
The generated ApiClient.java has this part there
public List<Pair> parameterToPairs(String collectionFormat, String name, Object value){
List<Pair> params = new ArrayList<Pair>();
// preconditions
if (name == null || name.isEmpty() || value == null) return params;
Instead of returning empty list params based on those preconditions, the code should check for the presence of the containerDefaultToNull option being set to true and also should check if the field is required or nullable, etc.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the issue with the provided OpenAPI YAML, the Java generator command, and a config containing containerDefaultToNull=true. Start in the generated ApiClient.java method parameterToPairs and trace how absent, nullable, and non-required list query parameters are handled. Done means the generated client distinguishes an omitted parameter from an explicitly empty list when the relevant option is enabled.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100