domaindrivendev
Swagger UI hangs on expanding method details
Last working version: Swashbuckle.AspNetCore 6.2.3 Updating it to 6.3.0 causes the error.
Expanding method hangs the whole page.
If I check 'Pause on exception' it shows the following error:
TypeError: Cannot read properties of undefined (reading 'declaringType')
If I let it continue, the following exceptions appears in the loop:
TypeError: Cannot read properties of undefined (reading 'declaringType')
TypeError: Cannot read properties of undefined (reading 'reflectedType')
TypeError: Cannot read properties of undefined (reading 'module')
TypeError: Cannot read properties of undefined (reading 'customAttributes')
We have also run into this error
What is particularly concerning in this case is that swagger ui keeps executing instead of bailing out. If I wait for a result for a minute the whole browser becomes unresponsive. Until it finally 'snaps'.
In our case it happens for a type that inherits from a base type while also implementing a mediatR IRequest interface. The interface is common and isn't the problem. It seems to be related to the base type or combination. But this isn't a 'special' or unusual situation - so we're a bit confused as why this is now suddenly an issue.
The use case is that we have a base type, which has properties for a number of other types, around 15 ish all in all. There is no recursion to the parent object. That's the first case I checked for.
~~We updated the package. And we also updated to .Net 7. Not sure if it is related. We have NOT setup trimming or AOT. So we don't anticipate those features are the cause in this case.~~
Edit: One of our developers just notified me that they previously encountered this issue in may 2022. Before we updated Swashbuckle to 6.4.0. So it wasn't caused by the update to .Net 7 nor by Swashbuckle update 6.4.0.
It was caused during update 6.2.3 to 6.3.1. And 6.4.0 doesnt' resolve it.
Also seeing similar. It is a pretty large 10M swagger.json and all the UIs and validators I've tried choke on it. Not sure if it's just the size or some circular reference that none of the UIs handle gracefully.
Hi @andrew-potachits , I had the same issue even with version 6.2.3. How I fixed the issue was, make sure you have scalar types and custom types in your api controllers requests and response models and not complex types, especially from third party or system types. In my case I had one endpoint record type model with BsonDocument type, so it hanged on startup. once i changed the property type to string it worked.
just try change things along these lines, and see if it will work for you. thanks!
This issue is stale because it has been open for 60 days with no activity. It will be automatically closed in 14 days if no further updates are made.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
The console errors suggest to me that a Type is getting into the schema somehow. If someone can provide a repro for some code that causes this issue we can take a look.
@martincostello I was able to reproduce the hang with the minimal project (https://github.com/andrew-potachits/test-swagger-ui-error.git)
The /WeatherForecast expands ok, but the expanding the /api/projects/transfer method hangs.
If the project references version v6.5.0, expanding api/projects/transfer fails, but if I change the reference to v6.2.3 and clean the browser cache (to reload the scripts), the method api/projects/transfer expands just fine.
While I prepared the project, the script didn't hang until I added the ApiVersioning + document filters, so probably the issue is related to one of the mentioned functions.
I can repro the hang with the provided GitHub repo, thanks.
If I try and load the same OpenAPI definition using Swagger UI 5.15.2 instead of then I get the same issue, but with a lot more feedback on the issues before things hang.
Looking at the OpenAPI spec itself, it seems to contain a lot of things that shouldn't be in there. For example, the first component declared in the schema appears to be an attempt to model an Assembly in JSON:
Assembly component
"Assembly": {
"type": "object",
"properties": {
"definedTypes": {
"type": "array",
"items": {
"$ref": "#/components/schemas/TypeInfo"
},
"nullable": true,
"readOnly": true
},
"exportedTypes": {
"type": "array",
"items": {
"$ref": "#/components/schemas/Type"
},
"nullable": true,
"readOnly": true
},
"codeBase": {
"type": "string",
"nullable": true,
"readOnly": true
},
"entryPoint": {
"allOf": [
{
"$ref": "#/components/schemas/MethodInfo"
}
],
"nullable": true,
"readOnly": true
},
"fullName": {
"type": "string",
"nullable": true,
"readOnly": true
},
"imageRuntimeVersion": {
"type": "string",
"nullable": true,
"readOnly": true
},
"isDynamic": {
"type": "boolean",
"readOnly": true
},
"location": {
"type": "string",
"nullable": true,
"readOnly": true
},
"reflectionOnly": {
"type": "boolean",
"readOnly": true
},
"isCollectible": {
"type": "boolean",
"readOnly": true
},
"isFullyTrusted": {
"type": "boolean",
"readOnly": true
},
"customAttributes": {
"type": "array",
"items": {
"$ref": "#/components/schemas/CustomAttributeData"
},
"nullable": true,
"readOnly": true
},
"escapedCodeBase": {
"type": "string",
"nullable": true,
"readOnly": true
},
"manifestModule": {
"allOf": [
{
"$ref": "#/components/schemas/Module"
}
],
"nullable": true,
"readOnly": true
},
"modules": {
"type": "array",
"items": {
"$ref": "#/components/schemas/Module"
},
"nullable": true,
"readOnly": true
},
"globalAssemblyCache": {
"type": "boolean",
"readOnly": true,
"deprecated": true
},
"hostContext": {
"type": "integer",
"format": "int64",
"readOnly": true
},
"securityRuleSet": {
"allOf": [
{
"$ref": "#/components/schemas/SecurityRuleSet"
}
],
"description": "\n\n0 = None\n\n1 = Level1\n\n2 = Level2",
"readOnly": true,
"x-enumNames": [
"None",
"Level1",
"Level2"
]
}
},
"additionalProperties": false
}
Lots of other types are then pulled in by association (CallingConventions, CustomAttributeData, ConstructorInfo, WebException, ...). That's clearly wrong.
There's a lot of custom schema generation code and API versioning code in the project.
Do you know off-hand why your customisations would be trying to include assemblies in the schema?
We didn't specifically pull all these entities. We had a few requirements that drove this customisation:
- Some API methods are internal only and were not supposed to be shown on the swagger index page
- At some point we started versioning our API, which is another customization source.
When I prepared the project I noticed that v6.5.0 didn't hang until I added those customizations, so if you have any idea what we did wrong or what can be done differently I would appreciate that.
This issue is stale because it has been open for 60 days with no activity. It will be automatically closed in 14 days if no further updates are made.
@martincostello we are going to migrate to .NET 8 in few weeks. Do you think the issue is still reproducible on the latest package version in .NET 8?
As far as I recall, when I did the test here https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/2511#issuecomment-2063279446 it was on the latest code in the default branch, so probably.
Based on the errors I saw, I don't think whatever was going wrong was a fault of Swashbuckle itself though.