Skip to main content

GraphQL.NET– Error when upgrading to .NET Core 3.1

After upgrading a .NET Core application to .NET Core 3.1, my GraphQL endpoint started to fail with the following error message:

System.InvalidOperationException: Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.

   at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.Read(Byte[] buffer, Int32 offset, Int32 count)

   at Microsoft.AspNetCore.Server.IIS.Core.WrappingStream.Read(Byte[] buffer, Int32 offset, Int32 count)

   at System.IO.StreamReader.ReadBuffer(Span`1 userBuffer, Boolean& readToUserBuffer)

   at System.IO.StreamReader.ReadSpan(Span`1 buffer)

   at System.IO.StreamReader.Read(Char[] buffer, Int32 index, Int32 count)

   at Newtonsoft.Json.JsonTextReader.ReadData(Boolean append, Int32 charsRequired)

   at Newtonsoft.Json.JsonTextReader.ParseValue()

   at Newtonsoft.Json.JsonReader.ReadAndMoveToContent()

   at Newtonsoft.Json.JsonReader.ReadForType(JsonContract contract, Boolean hasConverter)

   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)

   at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)

   at Newtonsoft.Json.JsonSerializer.Deserialize(JsonReader reader, Type objectType)

   at Newtonsoft.Json.JsonSerializer.Deserialize[T](JsonReader reader)

   at GraphQL.Server.Transports.AspNetCore.GraphQLHttpMiddleware`1.Deserialize[T](Stream s)

   at GraphQL.Server.Transports.AspNetCore.GraphQLHttpMiddleware`1.InvokeAsync(HttpContext context)

   at GraphQL.Server.Transports.WebSockets.GraphQLWebSocketsMiddleware`1.InvokeAsync(HttpContext context)

   at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)

   at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)

   at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.Invoke(HttpContext context)

   at Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware.Invoke(HttpContext httpContext)

   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

To fix it you can apply the suggestion as described in the error message:

But there is a good reason why Microsoft changed the default behavior in .NET Core 3.0 and disabled synchronous IO. It can be a source of thread starvation and application hangs.

The GraphQL.NET team is working on a new 3.0 release specifically created for .NET Core 3.0 but this is still in preview.

You can get the latest pre-release packages from the MyGet feed, where you may want to explicitly pull a certain version using -v.

dotnet add package GraphQL.SystemTextJson -v 3.0.0-preview-1448

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

VS Code Planning mode

After the introduction of Plan mode in Visual Studio , it now also found its way into VS Code. Planning mode, or as I like to call it 'Hannibal mode', extends GitHub Copilot's Agent Mode capabilities to handle larger, multi-step coding tasks with a structured approach. Instead of jumping straight into code generation, Planning mode creates a detailed execution plan. If you want more details, have a look at my previous post . Putting plan mode into action VS Code takes a different approach compared to Visual Studio when using plan mode. Instead of a configuration setting that you can activate but have limited control over, planning is available as a separate chat mode/agent: I like this approach better than how Visual Studio does it as you have explicit control when plan mode is activated. Instead of immediately diving into execution, the plan agent creates a plan and asks some follow up questions: You can further edit the plan by clicking on ‘Open in Editor’: ...