-
Notifications
You must be signed in to change notification settings - Fork 790
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reenable Transparent Compiler tests #17933
Conversation
❗ Release notes requiredCaution 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:
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
|
tests/FSharp.Compiler.Service.Tests/MultiProjectAnalysisTests.fs
Outdated
Show resolved
Hide resolved
EDIT: Nope, it's not this. Ok, I think I see where the bug is. I think there's a potential to simplify things here by introducing a |
But maybe, under stress, by the time control was returned to whoever called |
Ah, yes you're right. I was looking at this line
Which does a fire-and-forget task, but now I see the cache already has a value at this moment by earlier GetOrCompute .
|
f779f42
to
d51df4d
Compare
This showed up again in CI. I'm thinking now it's a genuine bug, not just test case being flaky. Too bad I can only repro it locally on an underpowered laptop. |
So, I was onto someithng after all. The test in question, fsharp/src/Compiler/Facilities/AsyncMemoize.fs Lines 550 to 557 in ae618aa
The problem is that there are none yet, despite the fact previous
fsharp/src/Compiler/Facilities/AsyncMemoize.fs Lines 474 to 475 in ae618aa
Effectively a state is allowed where the overall async computation continues but the cache is not keeping up. Ideally, the moment I do have a fix for this but it involves some refactoring 😟 |
Thanks for the further investigations :) Refactoring is okay as long as it is justified and not too crazy. |
Here's the gist of it: https://gist.github.com/majocha/6c075dcdabf45c3fd92b03e2cf3a07eb |
Good catch @majocha ! I don't know if this is a real issue in practice though. In this situation I think it's ok to say we don't have recent results yet. Alternatively it means some extra delay for the original caller waiting for cache update to be processed. If it's used in the usual async way, you'd get back the Unless I'm missing some other scenarios where this could be an issue, we could just update the test (maybe wait for cache event or something). I didn't study your refactoring in depth yet but it's much less code, so if it does the same thing I'm all for it! But maybe could be in a separate PR. |
Yes, in practice fixing the particular test would be just to add a wait for
That's what I'm thinking, first I want to get the tests up and running again. |
This actually cleared a huge blindspot for me. The whole thing I've been fighting here regarding the flakiness of these tests is that events can occur with some unpredictable delay. I did a lot of "clever" stuff here awaiting on the events but now it occurred to me: |
Good idea! Wonder if it takes care of all situations. It just might! We could potentially also consider waiting until there are 0 |
Yes it does, I just redid the AsyncMemoize tests also with it. Now I should probably crosscheck the test cases with their historical versions. They kinda went full circle and back with all the changes as I was fighting (having fun) with it. |
Yes, I considered this, but the cache state only gives no guarantee that there is no pending state update queued in the thread pool. |
Well yes, but also no state update (coming through |
I've been thinking in terms of testing, where we expect some exact list of events to be triggered. if there is a update posted, we have to wait because an event is coming. Once there are no more updates posted and we also don't have any |
This is now cherrypicked as PR to main #17966 |
Thanks Jakub ==> I am closing this one then. |
Experiment branched out from #17872
Async flavor of graph processing is simplified a bit and runs with Async.Parallel, given that it is async already.
If there are any remaining instabilities in Transparent Compiler tests they should be easier to weed out in a parallel test run, where the thread pool is way more stressed.
All the tests tests from #16766 but two should be unskipped, unless I missed some.