System.Net.Quic.Tests.QuicStreamTests.WriteCanceled_NextWriteThrows test failure #76831

Activity

1. jkotas

   added

   area-System.Net.Quic

   Known Build ErrorUse this to report build issues in the .NET Helix tabUse this to report build issues in the .NET Helix tab

   on Oct 10, 2022
3. ghost added

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Oct 10, 2022
4. wfurt

   removed

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Oct 10, 2022
5. wfurt

   added this to the 8.0.0 milestone on Oct 10, 2022
6. wfurt

   added

   test-run-coreTest failures in .NET Core test runsTest failures in .NET Core test runs

   on Oct 10, 2022
7. rzikm commented on Jun 14, 2023

   

   rzikm

   on Jun 14, 2023

   Member

   More actions

   The test is flaky and the failure happens on regular runs as well (but usually succeeds on reruns)

   The case seems to be when the cancellation happens to occur before the call to WriteAsync (and we call it with pre-cancelled token).

   runtime/src/libraries/System.Net.Quic/tests/FunctionalTests/QuicStreamTests.cs

   Lines 591 to 606 in 844702d

   	CancellationTokenSource cts = new CancellationTokenSource(500);
   	async Task WriteUntilCanceled()
   	{
   	var buffer = new byte[64 * 1024];
   	while (true)
   	{
   	await stream.WriteAsync(buffer, cancellationToken: cts.Token);
   	}
   	}
   	// a write would eventually be canceled
   	await Assert.ThrowsAsync<OperationCanceledException>(() => WriteUntilCanceled().WaitAsync(TimeSpan.FromSeconds(3)));
   	// next write would also throw
   	await AssertThrowsQuicExceptionAsync(QuicError.OperationAborted, () => stream.WriteAsync(new byte[1]).AsTask());

   We should have a look someday.
8. rzikm

   self-assigned this

   on Sep 6, 2023
9. rzikm commented on Sep 8, 2023

   

   rzikm

   on Sep 8, 2023

   Member

   More actions

   Okay, my original thought was wrong, we handle precancelled tokens correctly, there is actually very slim chance to repro this because many things have to align properly.

   the issue can be artificially enforced reproduced by adding sleep in

   • Abort (into if (abortDirection.HasFlag(QuicAbortDirection.Write)) branch)
   • WriteAsync (after if (!_sendTcs.TryGetValueTask(out ValueTask valueTask, this, cancellationToken))) or by making huge writes (e.g. 1 GB) to ensure that CancellationTokenSource fires while send is in progress

   What happens is that cancellation token sets Write state to cancelled and unblocks the Test task to progress, and it completes the clientFunction and Disposes the client QuicStream (i.e. completing the write direction gracefully), before the cancellation-registered action (which runs on a different thread) manages to finish the Abort call.

   In other words, if cancellation token fires while send is in progress, we may end up gracefully closing the write side :/
10. ghost added

    in-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged

    on Sep 19, 2023
11. ghost removed

    in-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged

    on Sep 19, 2023
12. rzikm commented on Sep 19, 2023

    

    rzikm

    on Sep 19, 2023

    Member

    More actions

    fixed by #90253
13. rzikm

    closed this as completedon Sep 19, 2023
14. karelz

    modified the milestones: 8.0.0, 9.0.0 on Sep 19, 2023
15. ghost locked as resolved and limited conversation to collaborators on Oct 19, 2023