Timeout sometimes waits the test to fully complete

[Thecentury]

According to https://stackoverflow.com/questions/55663039/async-startchild-with-timeout-and-sync-wait-inside-of-child-async, if test contains synchronous wait, Async.StartChild will wait for the inner async to run to completion.

So maybe is it worth to switch to some other timeout mechanism like task-based in the post above?

[haf]

Having the delay task complete, but not the test task, would leave a whole bunch of orphan tasks hanging; now what's the semantic when Expecto wants to shut down the process?

[Thecentury]

Hendrik, what's the problem with orphan tasks? Isn't the most frequent case for library like Expecto is to have the entire Main method looking like runTestsInAssembly ...? In this case entire process will shut down after running all tests, so all orphaned tasks will just stop executing too.

And why Expecto would shut the process down?

Now with current implementation of timeout one cannot get these two features:

• to get a failed test when inner code hungs for an indefinite time and
• to know which of tests from a test suite is hanging — because neither test actually fails.

[haf]

It's worth considering, but in that case having an async implementation that doesn't block the parent async indefinitely, perhaps by polling a variable.

[AnthonyLloyd]

Thanks, seems no end of gochas with Task and Async. I've been working lately on an IO (like ZIO) library and realized that Sleep, Wait and RunSynchronously are all really bad and used far too much even in framework code. The Task solution in the link still uses Wait and causes a thread to be blocked needlessly. Framework encourages this with WaitAny/WaitAll. For Async I've relied on Task too much and should have used Async.FromContinuations more.

I have timeout code that uses a Timer and race with no blocking that I can use. I may review other bit of the async code that waits. Would be amazing to move to IO but that would be a long way off.