Closed opolo closed 3 years ago
Found a temporary solution that does come with caveats though (see comments if anyone decides to use it): https://github.com/dotnet/aspnetcore/issues/7644
This blog post linked to the above issue, so credit where credit is due: https://khalidabuhakmeh.com/dotnet-core-3-dot-0-allowsynchronousio-workaround
Hope it can help someone else for now, if they face the issue :)
@opolo , thanks for reporting the issue and the workaround. From the test cases and the trace stacks, it looks like ASP.NET Core had some changes in its internal HTTP request body reading API implementation. We do have a rewind of the request body stream implemented as part of a workaround to keep APS.NET Core happy when it further processes the same request body. I suspect we might have to adjust the implementation of it based on the new ASP.NET Core 3.0 behavior. Also, I noticed you already use the Serilog logging framework within your application (and its middleware). In this case, I would recommend you try using our plug-in component for Serilog (basically implementing Rollbar Sink for Serilog) instead of the Rollbar middleware. The component distributed via Nuget as Rollbar.PlugIns.Serilog package. This way you get one less middleware in your HTTP request processing pipeline but will be able to capture every Serilog logging event as a Rollbar payload.
Hi!
I have to follow up on this: Any news on this, a short year after?
I'm to setup error tracking in one of my new client's backend APIs and want to suggest Rollbar - I am not keen on adding "hacks with caveats" in their BE though, as I am not that familiar with all their logic and thus the impact of this. Some enlightment on whether this still have to be added with .NET Core 3.1 would help in the decision.
Thanks! :)
Hi @opolo, I assumed the allow-sync-io-workaround resolved the problem for you. Before I start looking into it, may I reiterate your use case? You are planning to use RollbarMiddleware with the Asp.Net Core 3.1. Correct? Any plans on using Rollbar.NET with any other logging framework like Serilog?
One more question regarding the original stack trace you posted here to start this issue report: did you get an application crash with that exception/stack OR that is part of an exception reported by Rollbar.NET to your project dashboard on rollbar.com? Here is the way I would interpret the call stack: you use both Serilog's middleware and Rollbar middleware components. The Serilog middleware is an inner middleware as compare to the Rollbar middleware, hence, the Rollbar middleware would capture any unhandled exception (within its inner middleware chain) that reaches it. So, it (RollbarMiddleware) does seem to serve its purpose by capturing the exceptions triggered within the calls starting from the following call:
at Serilog.AspNetCore.RequestLoggingMiddleware.Invoke(HttpContext httpContext)
Does it seem correct from your perspective?
@opolo, please, try our v5.0.4-beta release of the SDK and see if that works better for you. It is a new major release, so some changes to the client code are expected (mainly around manually built configuration objects and explicit initialization of Rollbar infrastructure). v5 specific documentation is available here.
Hi Akornich! Thanks for letting me know! I will give it a spin in one of our services and see what happens :D NB. On vacation atm, so might take a couple of weeks. Aka. don't let me hold your new release captured till then by waiting for a response from me :)
@opolo , thanks for the update! Yes, the new release is code-complete at this point, we are clearing all the build warnings while waiting for feedback from the beta users (in case we need to make any changes to the SDK public APIs based on the feedback).
Optimistically moving this to closed. @opolo let us know if this should be reopened; thanks!
Describe the bug When I add
app.UseRollbarMiddleware();
to Startup.cs, all calls to APIs with endpoints containing complex data-type parameters fails. If I remove theapp.UseRollbarMiddleware();
they work again. GET calls with or without simple data types work, and so does POST calls without parameters.In other words, calling the following API action methods:
Succeeds:
GET -> public async Task<ActionResult> TestAsync()
GET -> public async Task<ActionResult> TestAsync(int numberParam)
POST -> public async Task<ActionResult> TestAsync()
Fails:
POST -> public async Task<ActionResult> TestAsync([FromBody] TestObjectClass testObjectParam)
TestObjectClass class is just a DTO with no methods apart from the constructor.
The error thrown is:
System.InvalidOperationException: 'Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.'
The stacktrace is:
Expected behavior No errors and 200 OK response.
Rollbar Client - Rollbar.NET Hosting Environment (please complete the following information):
Additional context Second critical error in two days after adding Rollbar :( First in Azure functions, now in ASP.NET Core. Does make us a bit nervous with the .NET compatibility, although we probably are just very unlucky... We will try to look into the error from an ASP.NET Core 3 point of view from our end. Perhaps some settings can be changed to avoid this issue, although we would hope for the changes not to be permanent modifications to our setup to avoid too many band-aids in the backend that needs maintenance during updates. We will share, if we learn something here.... Probably will not happen before tomorrow, as its night here in EU (just finished debugging of this... Was pretty hard to find the reason for the error due to an initial obscure stack trace not pointing us in the right direction... That was due to our bad exception middleware though, so lesson learned there the hard way!).