Improve AsyncMemoize tests

[0101]

Don't rely on arbitrary time delays to make the async tests work. This should hopefully avoid any flakiness.

[github-actions]

❗ Release notes required

@0101,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/8.0.300.md	No release notes found or release notes format is not correct

[0101]

Well now there's a bunch of random looking cancellation test failures. @auduchinok did you see something like this?

Link to test results

[auduchinok]

@0101 I wasn't been able to look into it yet, but I think I've seen something similar when tried to update our FCS fork.
Could you check if reverting #16348 in this branch will have any effect?

[0101]

@0101 I wasn't been able to look into it yet, but I think I've seen something similar when tried to update our FCS fork. Could you check if reverting #16348 in this branch will have any effect?

I put it in a separate branch #16536

[0101]

So the tests seem to be passing with #16348 reverted (here: #16536)

But all the failures also seem to be in my newly added code in Transparent Compiler. So I feel like I must be doing something wrong there with the thread static cancellation token.

[majocha]

I'm rather late to the party but I don't understand how can a [<ThreadStatic>] Cancellable.Token work in async context. There is no guarantee we'll stay on the same thread when executing a computation?

[0101]

I think it's only expected to work within node since there we make sure we move it over to a new thread when we switch.

[vzarytovskii]

I'm rather late to the party but I don't understand how can a [<ThreadStatic>] Cancellable.Token work in async context. There is no guarantee we'll stay on the same thread when executing a computation?

It's made for node builder, where we re-wrap thread static info (as we do with logger, etc).

[0101]

So the tests seem to be passing with #16348 reverted (here: #16536)

But all the failures also seem to be in my newly added code in Transparent Compiler. So I feel like I must be doing something wrong there with the thread static cancellation token.

Actually no, the failures don't only happen in the new code, since the experimental flag is not set in CI most of the tests are running with original BackgroundCompiler.

I still don't understand why it happens, I didn't find any computations that aren't guarded by Cancellable.UsingToken.

But still we should probably do the revert

[0101]

The fixes got included with #16536