Quarantine StreamPool_StreamIsInvalidState_DontReturnedToPool

[TanayParikh]

Failing Test(s)

• Microsoft.AspNetCore.Server.Kestrel.Core.Tests.Http2ConnectionTests.StreamPool_StreamIsInvalidState_DontReturnedToPool

Error Message

Assert.True() Failure
Expected: True
Actual:   False

Stacktrace

   at Microsoft.AspNetCore.Server.Kestrel.Core.Tests.Http2ConnectionTests.StreamPool_StreamIsInvalidState_DontReturnedToPool() in /_/src/Servers/Kestrel/test/InMemory.FunctionalTests/Http2/Http2ConnectionTests.cs:line 578
--- End of stack trace from previous location ---

Logs

Http2ConnectionTests_StreamPool_StreamIsInvalidState_DontReturnedToPool.log

Build

https://dev.azure.com/dnceng/public/_build/results?buildId=1651060&view=ms.vss-test-web.build-test-results-tab&runId=45546776&resultId=108023&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab

[amcasey]

This test hasn't failed in 30 days.

[amcasey]

Lines have moved, but it's probably this assert.

[amcasey]

The test is waiting for the stream to complete, but it's not obvious that that implies the stream will also have been disposed (which is what causes the output producer to be disposed).

[amcasey]

While it's not clear to me why we can assume that dispose will have been called before the tick handler returns, putting a delay ahead of the dispose call doesn't break the test.

[amcasey]

It certainly looks like the continuation of Pipe.CancelPendingRead is happening on the same thread and that's why the output producer is disposed by the time TriggerTick returns. This seems like it might not happen with a ThreadPoolScheduler, but locally, I'm seeing an InlineScheduler.

[amcasey]

It looks like the write scheduler is unconditionally inline, whereas the read scheduler comes from the ServiceContext.

Edit: ...which has an inline scheduler in this test.

[amcasey]

I can't explain what changed, but the code (linked above) doesn't look racy now.