Deflake TimeAwaitable finalizer test

[BrennanConroy]

Fixes #21517

I'm not really sure who was rooting this. I'm guessing some async state machine stuff since we do _ = new ObjectWithTimerAwaitable(tcs).Start(); so there could be a race where it's still rooted while we're running the GC

[halter73]

Below, we should be verifying Assert.True(tcs.Task.IsCompletedSuccessfully); to verify it didn't timeout.

I wonder why we need the while loop here and not in Kestrel's HttpConnectionManagerTests. Is it something about TimerAwaitable? I think the real fix might be to set the TimerAwaitable's dueTime to a very large value so you don't risk calling GC.Collect() while the timer is executing the callback.

aspnetcore/src/Servers/Kestrel/Core/test/HttpConnectionManagerTests.cs

Lines 25 to 35 in 100823a

	// Create HttpConnection in inner scope so it doesn't get rooted by the current frame.
	UnrootedConnectionsGetRemovedFromHeartbeatInnerScope(connectionId, httpConnectionManager, trace);
	GC.Collect();
	GC.WaitForPendingFinalizers();
	var connectionCount = 0;
	httpConnectionManager.Walk(_ => connectionCount++);
	Assert.Equal(0, connectionCount);
	trace.Verify(t => t.ApplicationNeverCompleted(connectionId), Times.Once());

Also, why is this test tracking _count? If anything I would check that Start() never finishes meaning the _timer is never disposed.

[BrennanConroy]

Below, we should be verifying Assert.True(tcs.Task.IsCompletedSuccessfully); to verify it didn't timeout.

Whoops.

I wonder why we need the while loop here and not in Kestrel's HttpConnectionManagerTests.

That test isn't doing anything async it looks like. I'm guessing that an async state machine is rooting the object so there is a race

[halter73]

I answered my own question. I think the real reason is we're "calling GC.Collect() while the timer is executing the callback." That's why I suggesting making the dueTime really large instead of adding this loop.

[halter73]

I kinda want to get rid of the loop to prove the dueTime theory.

[halter73]

Feel free to complain about me asking to remove the loop if it continues to be flaky. I just gotta know 😬

[BrennanConroy]

I ran it 10000 times without the loop and it's reliable now. Before it would fail with less than 1000 runs.