openapi-generator: [BUG] [Java] Nullable field failing when explicitly set to "null"
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
In our OpenAPI spec, we have a model with a nullable field called “prev_page_url”. If we test the generated code (with generator v6.0.0) omitting the parameter, it works correctly.
If instead we test setting the field explicitly to null we obtain the following error:
Expected the field `prev_page_url` to be a primitive type in the JSON string but got `null`
openapi-generator version
v6.0.0
OpenAPI declaration file content or URL
The parameter is defined here, and the main spec can be found here
title: Pagination
type: object
description: ''
properties:
current_page:
type: integer
description: Current page number.
nullable: true
first_page_url:
type: string
format: uri
description: First page url.
nullable: true
from:
type: integer
nullable: true
description: First result of the page.
last_page:
type: integer
description: Last page number.
nullable: true
last_page_url:
type: string
format: uri
description: Last page url.
nullable: true
next_page_url:
type: string
format: uri
nullable: true
description: Next page url
path:
type: string
format: uri
description: Request path.
nullable: true
per_page:
type: integer
description: Number of result per page.
nullable: true
prev_page_url:
type: string
format: uri
nullable: true
description: Previous page url.
to:
type: integer
nullable: true
description: Last result of the page.
total:
type: integer
description: Total number of results
nullable: true
Generation Details
Our github action can be found here openapi-generator-cli generate -i ./openapi.yaml -g java -o ./generated/java/
Steps to reproduce
obtain a JSON response with the parameter set as follows:
{
"prev_page_url":null
}
Related issues/PRs
I couldn’t find any…
Suggest a fix
In this case, Gson doesn’t set the param to null, but to an instance of JsonNull class. To check it should be able to change the pojo.mustache template in this way:
if (({{^isRequired}}jsonObj.get("{{{baseName}}}") != null && {{^isRequired}}jsonObj.get("{{{baseName}}}").isJsonNull()) && {{/isRequired}}!jsonObj.get("{{{baseName}}}").isJsonPrimitive()) {
If you want, I can try to prepare a PR for this issue.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 6
- Comments: 23 (8 by maintainers)
Hi, I prepared a PR for this https://github.com/OpenAPITools/openapi-generator/pull/12630 I’ll try to launch the sample generation as soon as possible, to make it acceptable for the team.
Im using v6.2.1 and am generating a Java client with:
When any property is null, even if including
nullable: truein the definition, egExpected the fieldcurrencyCodeto be a primitive type in the JSON string but gotnull``Is this fixed by the PR above? It doesnt seem to be for Java
I’m also seeing this issue with
required: truein combination withnullable: truein Version 6.6.0. Whenever the value is “null”, the validation is throwing an Exception for trying to cast gson.JsonNull to gson.JsonObject.I’m also seeing this issue with a
required,nullable,readOnlyobject string property. Particularly the issue seems to be when mixing bothnullableandrequired.I’m on the latest 6.4.0 and still seems to be an issue for arrays when explicitly set to null in the JSON response. The issue in the mustache seems to be this part, perhaps it should also do a check for isJsonNull()?
This fix works for me (using v6.3.0), so should probably be closed
@aaron-613 I just modified one mustache file… and then launched the generator to update the example files
Hi @aaron-613 my PR was merged, but I think it will be released in the next milestone. https://github.com/OpenAPITools/openapi-generator/pull/12630
I’m affected by this issue as well and I am interested in fixing it. I will submit a PR for it if @valmoz is not already working on it.