Resolver errors in generated swagger UI using OpenApi.Core 3.0.0
ccruden-shookiot opened this issue · comments
When I expand certain of the endpoints in the swagger UI from my function app, I get errors resolving certain types:
Resolver error at paths./TagMap/{Id}.delete.responses.204.schema.$ref
Could not resolve reference: Could not resolve pointer: /definitions/int32 does not exist in document
The errors seem to be linked to the response of the functions. Every function I have is flagged with OpenApiResponseWithBody and most return a bodytype of a local class. The ones that return something based on simple base types (either typeof(int) or typeof(List<int?>)) return the errors.
I'm using just Aliencube.AzureFunctions.Extensions.OpenApi.Core (3.0.0) and the boilerplate code from ...OpenApi (OpenApiHttpTrigger/IOpenApiHttpTriggerContext/OpenApiHttpTriggerContext with AuthorizationLevel.Anonymous instead of Function). I don't remember similar problems happening when using 2.1.0, so perhaps a bug slipped in?
Looking at the generated json (attached), the references (to /definitions/int32 and /definitions/nullable`1 are definitely missing.
swagger.zip
@ccruden-shookiot Thanks for the issue!
It seems that there are multiple issues happening at the same time:
- The HTTP status code of 204 basically means there's no response payload. Therefore, for your case, it's better to use
OpenApiResponseWithoutBodyAttribute. - If you use
Aliencube.AzureFunctions.Extensions.OpenApi.Corepackage, you should take care ofOpenApiHttpTriggerthat handles Swagger UI and Open API document generation by yourself. - The
/definitions/node should only include object types, not the data type likeInt32orString. If they are included, it would be definitely a bug – I'll chase that up.
I'll have a look your zip file.
A few good points there....
The example I used apparently is coded in a weird way - for some reason it's a WithBody attribute, but the code is HttpStatusCode.NoContent, and it indicates it returns a typeof(int), but the code actually doesn't. Probably some changes made and someone forgot to change everything. I went through and fixed up the functions whose OpenApiResponse* attributes didn't match with their code, and that eliminated some of the resolver errors but not all. For instance:
Resolver error at paths./TagMap/Batch.post.responses.200.schema.items.$ref
Could not resolve reference: Could not resolve pointer: /definitions/nullable`1 does not exist in document
The attributes in code for that function are:
[OpenApiOperation("post", "TagMap")] [OpenApiRequestBody(contentType: "application/json", bodyType: typeof(List<TagMap>))] [OpenApiResponseWithBody(HttpStatusCode.OK, "application/json", typeof(List<int?>))]
and it does return the List<int?> it describes on success.
OpenApiHttpTrigger (and associated class / interface) I cribbed from the code force included from Aliencube.AzureFunctions.Extensions.OpenApi. I then removed that nuget from the project and added the files back in manually, with the small change to the AuthorizationLevel on each (Anonymous instead of Function). That way I get the default document generation and can still check the files into source code so everything builds properly.
It looks like pull request 104 has been merged into OpenApi.Core 3.1.0, but I still have this problem using that version of the package.
@ccruden-shookiot Could you please try the new release, https://www.nuget.org/packages/Aliencube.AzureFunctions.Extensions.OpenApi/3.1.1 and let me know how it works?
I'm going to close this issue for now. If you still have an issue, please feel free to open it again.
3.1.1 does indeed fix the issue for me.