-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong documentation when nullable property is used in a field that maps to object #3518
Comments
This is going to be challenging to investigate. Looking at the linked issue, it looks like you're using springdoc, and they sent you here because they claim to be using our processor (which they might). However, officially, we don't support Spring MVC/Boot as they use a different annotatiions to describe operations. We're very grateful for the sample project, however, in order to isolate that the issue really is in swagger-core and not springdoc, we'd need a sample that's based on JAX-RS and not spring boot to reproduce it. Is there any chance you can produce such sample? |
Hi @webron, Here's a sample code (pure java) that helped us confirm the reproduce. I wish it could help. ResolvedSchema resolvedSchema = ModelConverters.getInstance()
.resolveAsResolvedSchema(new AnnotatedType(MyResponse.class));
if (resolvedSchema.schema != null) {
Schema schemaN = resolvedSchema.schema;
Map<String, Schema> schemaMap = resolvedSchema.referencedSchemas;
StringSchema stringSchema = (StringSchema) schemaMap.get("MyResponse").getProperties().get("nonNullableField");
if (stringSchema.getNullable() == null) {
throw new IllegalArgumentException("nonNullableField, should not be null");
}
} |
Is there any progress on this issue? |
Any progress? |
any progress? |
Hello :) Any progress on this bug ? |
First thing, the expected definition like:
is incorrect. Becase "$ref" replaces definition, and all sibling properties it will be ignored. See https://swagger.io/docs/specification/using-ref/ .
So, event if this is forced, the importing tools will likely ignore it. I think expected variant is:
However it is not easy to implement becase the ref still wanted even if oneOf specified in swagger. I have put extension on the container object:
Note, extensions are ignored on ref properties as well. Then I wrote OpenApiCustomiser customizer in Spring that walks over schema and does the following:
Basically, it extension presents, it converts all ref properties mentioned in it to oneOf and then remove extension from schema. This works for me, because with have a single consumer of the result schema that understands this variant. Result could differ for other tools. I think the correct implementation would be if anything property-specific like description, nullable, extensions are specifed for reference type, then oneOf type should be automatically used with a single candidate, and other things should be put near oneOf. Note that even for nonNullableField the description is lost, and this is an information loss because we now do not know what is local semantics of the field as $ref specifies global semantics and syntax. |
@const sorry for the late reply. I didn't test your suggestion, but I did some things in my example to work around the issue: using Jakarta (previously Javax) annotations: @Value
public class MyResponse {
@NotBlank
@Schema(nullable = false, description = "DOES NOT map to json object and DOES NOT allow null")
private final String nonNullableField;
@Schema(nullable = true, description = "DOES NOT map to json object and DOES allow null")
private final String nullableField;
@Schema(nullable = false, description = "DOES map to json object and DOES NOT allow null")
@NotNull
private final MyClass nonNullableObjectField;
@Schema(nullable = true, description = "DOES map to json object and DOES allow null")
private final MyClass nullableObjectField;
@ArraySchema(arraySchema = @Schema(nullable = false, description = "list that DOES NOT map to json object and DOES NOT allow null"))
@NotEmpty
private final List<String> nonNullableList;
@ArraySchema(arraySchema = @Schema(nullable = true, description = "list that DOES NOT map to json object and DOES allow null"))
private final List<String> nullableList;
@ArraySchema(arraySchema = @Schema(nullable = false, description = "list that DOES map to json object and DOES NOT allow null"))
@NotEmpty
private final List<MyClass> nonNullableObjectList;
@ArraySchema(arraySchema = @Schema(nullable = true, description = "list that DOES map to json object and DOES allow null"))
private final List<MyClass> nullableObjectList;
} Which results in the following specification (just the important bit): {
"MyResponse": {
"required": [
"nonNullableField",
"nonNullableList",
"nonNullableObjectField",
"nonNullableObjectList"
],
"type": "object",
"properties": {
...
}
}
} |
In regards to the
And its implementation:
Their example makes things even weird: a How nobody thought that a component that's suppose to be reused in many places could:
I hope they can review this design/implementation decision in a 3.2.x API definition. Anyway, I appreciated the time you spent replying to my issue. |
Same Issue here. We have this class setup: @Schema(title = "Payment") |
@elgleidson @Burtsev-Alexey Hi, sorry for pinging but, out of curiosity, have you tried to generate 3.1 openapi specification ? Does the problem still appear ? |
I am closing this ticket for now, feel free to reopen if there will be still any issues even with 3.1 generated spec |
@Burtsev-Alexey |
@micryc Thank you, i have switched to 3.1 and now schema is generated properly I see: The minor problem is titles are not displayed with 3_1 in swagger-ui, but this is other problem I will probably figure this out some day... So I think this issue is resolved. |
First of all, the following repository has all the code (and description as well) to reproduce this problem: https://github.com/elgleidson/swagger-problem
I have the following JSON:
Which is mapped to the following Java classes:
When I go to
/v3/api-docs
(or/swagger-ui.html
) the following documentation is generated:As you can see, for the fields whose types are not mapped to
object
the documentation is generated as expected. The same doesn't happen fornullableObjectField
: thenullable
property is put inMyClass
definition instead of the field.The following documentation should be generated instead:
The text was updated successfully, but these errors were encountered: