Starting point for thorough testing of AsyncLocal impact #16701
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
|
…into asynclocal-compare
|
At the moment I'm not sure how to continue with this in light of #16712. |
I guess disregard anything Transparent Compiler related in the testing? Since that possibly doesn't work correctly now it's not something we can compare against. But presumably what was there before does work, so we could just check if that stays the same. |
…into asynclocal-compare
…into asynclocal-compare
…into asynclocal-compare
|
I'm afraid this is impossible task. I think threadstatics behavior is not 100% deterministic in tests, I even see different results depending on how many tests I run simultaneously. Nothing is fully reproducible here, it just kind of eventually converges on some final state. |
I think it should be possible to have more (lots of? 🙂) asserts in tests, maybe? They would check that, for example, we don't have diagnostics without logger or in a wrong phase. |
|
Yes, one thing we had was the |
This keeps a shadow diagnostics async state in AsyncLocals, and compare it with the current implementation, failing whenever they diverge.
The idea is to find out when and why it happens and to bring the behavior to some unification, so we can be sure AsyncLocal is a valid and safe replacement for current ThreadStatics + NodeCode.
It's useful to run some tests in debug, with the setting to break on
System.Exception.Then we can not only observe what diverged:
but also view the log of changes:
with some, not often useful, call stacks:
