-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Race in scoped services promoted to singleton caching #52863
Comments
Tagging subscribers to this area: @eerhardt, @maryamariyan Issue DetailsThe #52484 attempted to fix the race where The former presumes the value is cached in callSite.Value the latter in The problem with the fix is that it only tightened the race for directly resolved services but did nothing for indirectly-resolved ones. For the following chain:
When A is resolved B is also resolved and cached into the
|
I think this test illustrates the problem: [Fact]
public void ScopedServiceResolvedFromSingletonAfterCompilation2()
{
ServiceProvider sp = new ServiceCollection()
.AddScoped<A>()
.AddSingleton<IFakeOpenGenericService<A>, FakeOpenGenericService<A>>()
.BuildServiceProvider();
var scope = sp.CreateScope();
for (int i = 0; i < 10; i++)
{
scope.ServiceProvider.GetRequiredService<A>();
Thread.Sleep(10); // Give the background thread time to compile
}
Assert.Same(sp.GetRequiredService<IFakeOpenGenericService<A>>().Value, sp.GetRequiredService<A>());
}
|
The #52484 attempted to fix the race where
CallSiteRuntimeResolver.Instance.Resolve
and compiled service accessors have a different source of truth for a scoped services promoted to singletons caching location.The former presumes the value is cached in callSite.Value the latter in
ResolvedServices
dictionary on the scope.The problem with the fix is that it only tightened the race for directly resolved services but did nothing for indirectly-resolved ones.
For the following chain:
A(Singleton)->B(Scoped)
When A is resolved B is also resolved and cached into the
callSite.Value
. When a direct compiled accessor forB
is executed on the root scope it would bypass the logic in the fix and would use the ResolvedService collection, skippingcallSite.Value
entirely.The text was updated successfully, but these errors were encountered: