Scoped class in SignalR not resolving to existing one already created.

[Buildstarted]

Describe the bug

I've created a scoped class that is populated in some middleware. This could be a settings object or permissions object or whatever.

Using the scoped object in a constructor of an mvc controller I get that value I expect. However, using the same scoped object in the constructor of a hub I get a newed up instance of the scoped class.

I have verified that the middleware is being called when the endpoint for the hub is hit.

To Reproduce

Steps to reproduce the behavior:

1. Using this version of ASP.NET Core : 3.0 preview 8 013656 (though it affected the previous preview as well)

Gist with sample project

Expected behavior

As with MVC I expect when resolving a scoped object that it retrieves the object that has already been created and subsequently modified in the middleware.

It's possible that this is intended and if so how can I reliably retrieve scoped objects in signalr?

[Buildstarted]

Looks like DI doesn't work in this context possibly due to the creation of a child scope? You can resolve dependencies via Context.GetHttpContext().RequestServices

[rynowak]

What you're seeing is expected because there are two requests happening here, and thus two scopes.

• Your original page load is a an HTTP request that gets static HTML (from MVC)
• Then the browser sends a second HTTP request to open a websocket and connect to SignalR.

Can you prove some more information about what you want to accomplish, so we can try to help?

[Buildstarted]

Right and I understand that. This was simply an example to show that MVC requests work properly to resolve the scoped dependency while a hub doesn't.

client -> middleware -> mvc (testobj is the same from middleware)
client -> middleware -> hub (testobj isn't the same from middleware for the initial connection)

Since hubs are shortlived and as time goes on the testobj from the middleware will get stale since the middleware isn't called for each message that comes through. I suppose this is why scoped depedancies are not properly resolved since each message doesn't get a full scope but it is definitely confusing.

[BrennanConroy]

Because hubs are abstracted away from the underlying connection we don't know if there was a new request or the same request just streaming more data.

And because there are multiple ways to connect in SignalR (both a new http request per hub method invoke and a single long-running request for all hub method invokes) we need to treat each hub method call as a different request to have a consistent experience across different connection types.

TLDR: every hub method call we create a new service scope and resolve services from that scope.

[halter73]

SignalR does not use the request DI scope. It creates its own scope per hub-invocation. This is partly due to the possibility of a single request triggering multiple invocations. Creating some sort of hub pipeline module to configure your service might be an alternative/addition to the middleware once we add a hub pipeline. #5353

[Buildstarted]

Thanks, @halter73. Looking forward to the future. Since you don't use the underlying HttpContext how reliable is RequestServices (assuming all connections are over websockets)?

[ghost]

Thank you for contacting us. Due to no activity on this issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

[halter73]

@Buildstarted Sorry I missed your comment until just now. SignalR manually creates a "request" scope per invocation, so it should be very reliable.

https://github.com/aspnet/AspNetCore/blob/0d02d7a7051edebf24fc2ba92d0172f741f53455/src/SignalR/server/Core/src/Internal/DefaultHubDispatcher.cs#L218