I've been unable to reproduce. Though I am not testing on windows.

In this (and other) tests, it waits for up to 5 seconds to close the row after it is canceled. So far I've been unable to reproduce the failure. But this type of failure could be from too much load and the goroutine that will close the row, to not get scheduled in that grace time.

We could remove the local timeout, but that doesn't seem ideal either. I'm unsure how to handle this.

But this type of failure could be from too much load and the goroutine that will close the row, to not get scheduled in that grace time.

Note that the test failure in the above snippet ran the test for nearly 6 minutes before failing. (As of CL 378395, the test should be much less sensitive to specific timing issues.)

If this sort of test fails, would a goroutine dump show what is holding the rows open? If so, perhaps have the test call debug.SetTraceback("all") and panic instead of calling t.Fatalf.

Or, would it be possible for the test to log more information about the lifecycle events for the connections that are still open?