-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Avoid replacing realized service cache for singletons #52484
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
…gltons - Scoped services resolved from the root container are singletons. This fixes a regression that caused the dynamically compiled callsite for scoped service to create new instances for scoped services resolved from root providers. - Added a test and added an optimized path that does not compile singletons and promoted singletons using the background thread.
|
Tagging subscribers to this area: @eerhardt, @maryamariyan Issue Details
Fixes dotnet/efcore#24824
|
| for (int i = 0; i < 10; i++) | ||
| { | ||
| Assert.Same(singleton, sp.GetRequiredService<A>()); | ||
| Thread.Sleep(10); // Give the background thread time to compile |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😨
| } | ||
|
|
||
| [Fact] | ||
| public void ScopedServiceResolvedFromSingletonAfterCompilation() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we also want to test a use case where a scoped service is registered in a scoped service provider and is depending on a singleton service?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the same loop? I want to say I'm sure we have that scenario covered, but never say never 😄
|
Merging to unblock upstream |
Fixes dotnet/efcore#24824