Synchronous operations after batch request

[kaihueb]

some OData batch requests result into internal error since synchronous calls are are not allowd in .net core 3.1

Assemblies affected

Microsoft.AspNetCore.OData (7.3.0)
.net core 3.1

Reproduce steps

call OData batch request with JSON body/response e.g.

{
    "requests": [
        {
            "Id": "1",
            "method": "DELETE",
            "headers": {
                "odata-version": "4.01",
                "content-type": "application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false"
            },
            "url": "Entity(6)",
            "body": ""
        }
    ]
}

where the entity does'nt exists and the controller is returning NotFound()

Expected result

with the the workarround (disable check) I get the expected result, without this setting I get an internal error

webBuilder.ConfigureKestrel(options =>
{
options.AllowSynchronousIO = true;
});

Actual result

Internal error

Additional detail

System.InvalidOperationException: Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpResponseStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
at Microsoft.OData.JsonLight.ODataJsonLightBatchWriter.FlushSynchronously()
at Microsoft.OData.ODataBatchWriter.Flush()
at Microsoft.OData.ODataBatchWriter.WriteEndBatch()
at Microsoft.AspNet.OData.Batch.ODataBatchContent.WriteToResponseMessageAsync(IODataResponseMessage responseMessage)
at Microsoft.AspNet.OData.Batch.DefaultODataBatchHandler.ProcessBatchAsync(HttpContext context, RequestDelegate nextHandler)
at Microsoft.AspNet.OData.Batch.ODataBatchMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)

[xuzhg]

@kaihueb Thanks for reaching us.

We do have the similar configuration in our codes at:

WebApi/src/Microsoft.AspNetCore.OData/Formatter/ODataInputFormatter.cs

Lines 123 to 127 in 4eb6b7f

	var body = request.HttpContext.Features.Get<AspNetCore.Http.Features.IHttpBodyControlFeature>();
	if (body != null)
	{
	body.AllowSynchronousIO = true;
	}

It seems we forgot to add similar codes for $batch. We will investigate it and close the gap.

[mikepizzo]

We try to write the batch stuff asynchronously so that we don't have to set AllowSynchronousIO for the overall batch. However, there appear to be some bugs in our batch async logic, where we call synchronous methods. I have a fix.

[hfaran]

@mikepizzo @xuzhg We're still seeing some errors related to this even with the new 7.4.0 release. Here is the particular stack trace; looks like there is still sync IO being used in places:

    System.InvalidOperationException: An error occurred while processing this request. ---> System.AggregateException: One or more errors occurred. (Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true.) ---> System.InvalidOperationException: Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true.
  Stack Trace: 
    ResponseBodyWriterStream.Write(Byte[] buffer, Int32 offset, Int32 count)
    MessageStreamWrappingStream.Write(Byte[] buffer, Int32 offset, Int32 count)
    AsyncBufferedStream.FlushSync()
    ODataRawOutputContext.FlushBuffers()
    ODataMultipartMixedBatchWriter.StreamRequested()
    ODataBatchOperationMessage.GetStream()
    ODataBatchResponseItem.WriteMessageAsync(ODataBatchWriter writer, HttpContext context, Boolean asyncWriter)
    ODataBatchContent.WriteToResponseMessageAsync(IODataResponseMessage responseMessage)
    DefaultODataBatchHandler.ProcessBatchAsync(HttpContext context, RequestDelegate nextHandler)
    ODataBatchMiddleware.Invoke(HttpContext context)
    <<UseBranchWithServices>b__1>d.MoveNext() line 77
    --- End of stack trace from previous location where exception was thrown ---
    <<UseBranchWithServices>b__3>d.MoveNext() line 92
    --- End of stack trace from previous location where exception was thrown ---
    MapMiddleware.Invoke(HttpContext context)

[mikepizzo]

Thanks for the report; stack trace helped find the call to synchronous GetStream, which resulted in a sychronous write down further down the stack. Verified that calling GetStreamAsync() calls the right async write methods further down the stack. Would love to have you check nightlies once this is checked in to make sure we didn't miss any other cases.

[hfaran]

Thanks @mikepizzo. I'm ready to pick up the nightly as soon as it's available.

[mikepizzo]

Fix is in PR #2149.