API获取和浏览器崩溃后,Swagger UI冻结

gzjq41n4  于 2022-11-06  发布在  其他
关注(0)|答案(8)|浏览(325)

我有一个ASP .NETWebAPI项目,我正在尝试用Swagger UI替换旧的XmlDocumentationProvider页面。我使用的是swashbuckle swagger for webAPI 5.3.1 nuget包。
我可以导航到localhost/MyApp/swagger,我可以在fiddler中看到它调用localhost/MyApp/swagger/docs/v1来检索代表我的API的JSON字符串。调用成功,JSON大约为240 KB,并且JSON是有效的。此时,chrome选项卡冻结了大约30秒,然后崩溃,出现“Aw snap”页面。控制台中没有错误。
尝试验证this online validator中的api JSON是有效的,并且说明规范/架构是有效的,如果并且仅当我取消选中所有三个“Follow ___ $refs”复选框。如果选中了其中任何一个复选框,则需要大约30秒,然后该工具崩溃。
不幸的是,我不能将我的整个webAPI规范粘贴到某个地方,但是我可以说,它是用于非常大和非常复杂的内部业务应用程序的。(与DTO本身类型相同的属性),我怀疑这可能会导致问题,但在没有任何日志记录或调试的情况下,我无法确定,并且有超过1000个DTO类,我不想一一检查。
有没有办法打开swashbuckle(在服务器上)或swagger UI(在客户端上)的任何类型的日志记录或调试?有人遇到过浏览器崩溃的问题吗?知道是什么原因导致的吗?提前感谢。

uplii1fm

uplii1fm1#

我能够注解掉我的每个API控制器,加载swagger页面,然后重新打开它们,直到页面再次崩溃。一旦我找出了哪个控制器有问题,我就对控制器中的所有端点重复这个过程。
原来,我们的一个非常旧的方法是将ORM实体作为主体参数(非常糟糕),这导致swagger试图解析整个ORM对象图并耗尽内存。将此方法更改为接受DTO而不是数据层实体解决了该问题。

lvmkulzt

lvmkulzt2#

我认为这是一个已知的错误,当你使用非标准的序列化程序或配置你的web api是非标准的。
这是一个循环引用问题。
请参阅git hub存储库中的问题:https://github.com/domaindrivendev/Swashbuckle/issues/486

qyuhtwio

qyuhtwio3#

如果其他人遇到这个问题,并且似乎没有任何帮助,下面是我在我们的代码中发现的。
我们找了一个人来编写我们的API,他肯定已经自动导入了一堆基于DB Schema的类,但它所做的是创建大量引用其他分部类的分部类,而这些分部类又反过来引用了原始类。
所以这最终成为了一个循环引用的问题,就像上面提到的,但并不完全一样。我花了一段时间才弄清楚有什么不同,但当我注解掉对其他分部类的引用时,一切都运行得很好。
我的建议是结合上述两个答案,使用您自己的DTO,并确保您没有循环引用。
另一个重要的问题是[Route()]标签,这个家伙在POST/PUT方法的参数中放置了[Route("{model}"],他使用[Route("{model}")]标签解析模型的JSON主体,所以在Route标签中放置它是不必要的,这会导致问题。它应该是[Route("")]

tez616oj

tez616oj4#

检查你的api方法的ResponseType属性。在我的例子中,当我修改一个api方法的时候,我忘记删除responsetype,因为我删除了返回一个对象。

ma8fv8wu

ma8fv8wu5#

我也遇到了同样的问题。最后我可以让我的[ResponseType()]按照我的意愿与ORM实体保持原样,但是我设法通过在[SwaggerResponse()]中添加另一个模型来使swagger不冻结
以下是更多信息:https://mattfrear.com/2015/04/21/generating-swagger-example-responses-with-swashbuckle/

46qrfjad

46qrfjad6#

我们有一个来自NetTopologySuite.Geometries命名空间的“Point”类,它使swagger崩溃。

cbeh67ev

cbeh67ev7#

我一直在试图找到Swagger UI产生这种“页面无响应/您可以等待它成为响应或退出页面。”对话框的原因(因为它出现在Chrome。)Chrome偶尔会发出“啊,啪!错误代码:内存不足。”
[Edge和Firefox行为类似。]
如果我重复地告诉浏览器等待,大约一打或二十打,请求最终会成功。这显然是一个不确定的、间歇性的bug。因此,它不太可能是某种循环引用的结果。看起来Swagger UI只是使用了太多的内存,导致了浏览器超时。
我的WebAPI已经发展到大约55个路由;但我怀疑问题可能源于底层实体框架DbContext的复杂性,看起来Swashbuckle在生成其WebAPI模式期间对DbContext执行反射;但我不太熟悉它的实际工作原理。
我第一次遇到这个问题是在ASP.NETCore3.1中;但我目前的目标是.NET6Preview5。
我尽量让软件包保持最新;并且当前的Swashbuckle. AspNetCore版本为6.1.4。
我已经尝试从项目中排除Web API的每个子路径。只有在我删除了所有引用DbContext的路由时,这种方法才开始起作用。
我还有其他基于更简单的EF数据模型的Web API项目,其中Swagger UI工作得很好。

9o685dep

9o685dep8#

我经历了同样的像阿梅尔与“点”类从NetTopologySuite.Geometries。评论出来解决了问题。

相关问题