-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Fix eagerly executed task in CustomSettingService #15942
Conversation
WalkthroughWalkthroughThe update in the Changes
Recent Review DetailsConfiguration used: CodeRabbit UI Files selected for processing (1)
Additional comments not posted (2)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
Bad rabbit! Not for performance at all. |
@sebastienros indeed this fixed the issue! Great find! |
Good job! Shouldn't YesSql have a config that throws an exception on parallel queries? So, what you have locally, but don't break but throw an exception. |
Fix #15794
Fix #15628
How I found it:
On the right the DocumentManager saved a document (Roles) and this is rooted by an HttpRequest. On the left there is no specific root, which seems weird. So I looked at this
CustomSettingService.GetContentTypeAsync
. Weirdly, it's invoked in aLazy<>
in the constructor ...and this is it, the lazy is initialized with the running Task because the method is invoked directly:
GetContentTypeAsync()
It used to work, before this commit as the code was
The important thing is not
async/await
it's the fact that it's a lambda, soLazy<>
will invoke it only when.Value
is called. After the recent change it was actually invoking theLazy<T>(T value)
overload which is not lazy at all.The solution is to have a lambda or a method group, which this PR is doing.
Summary by CodeRabbit