-
Notifications
You must be signed in to change notification settings - Fork 831
Yet another NodeCode problem affecting AsyncMemoize #16712
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
Conversation
38e04e3 to
0cbbd65
Compare
✅ No release notes required |
|
Wait, so are there wrong thread static in the Also, does switching to |
|
From my understanding, once we're in normal async, the flow of diagnotics state stops. So every time there is a thread switch in async, we end up with a wrong or null logger. This corrupts other running nodes, as long as there are any any diagnostics updates or, even worse, swapping of global diagnostics logger in such an async task. I guess this is not very impactful because almost everything we have is wrapped in node. And yes, AsyncLocal does not have that problem. |
|
There are some things that further mask this problem. For example, we have implicit initialization if there happen to be a null logger in DiagnosticsThreadStatics getter. I tried to remove this initialzation and swap it for explicit initialization at service boundary (any FCS service call sets defaults first). I then observed naked nulls showing up in AsyncMemoize.Get. So it seems the corruption sometimes gets through. |
|
Hmm, so basically we shouldn't have anything that is not Anyway this seems like another good argument to switch to AsyncLocal. |
|
Yes, that's exactly it. At least nothing that has potential to produce diagnostics or modify the global diagnostics logger should be executed. |
|
One thing I noticed is |
|
Hey @majocha , is this PR good to go or are you planning to make some more improvements or tests? |
|
This is more an issue than a PR, I will close this to not clutter things. |
It looks like any call to
NodeCode.AwaitAsync(there are many in Transparent Compiler) is at risk of getting wrong threadstatics?I've seen some randomness of that kind in #16701. Mostly the threadstatics get eventually restored at some point, but the potential for chaos is there.
I also added a modified AsyncMemoize test to show the problem.