WorkContext is null if client transport is webSockets

[Former user]

Hello! WorkContext is null in scope of HubMethod if client transport is webSockets Scenario to reproduce: Use latest Proligence.SignalR with webSockets enabled. Create ServiceHub and Try to call TryGetWorkContext method from client:

    public class ServiceHub : Hub
    {
        private readonly IOrchardServices services;

        public ServiceHub (IOrchardServices services)
        {
            this.services = services;
        }

        private bool TryGetWorkContext ()
        {
            if (services.WorkContext != null)
            {
                return true;
            }
            return false;
        }
    }

Actual Result: services.WorkContext is null. Expected Result: services.WorkContext is not null

If client use longPolling or SSE everything works fine.

[Piotr Szmyd]

I'm aware of this issue. Unfortunately haven't yet found out a reasonable solution although have a few ideas.

The thing with websockets is that after establishing a connection there are no more requests happening when data is sent back and forth. SignalR spawns a long-running listener task in the background instead in this case, bypassing the request pipeline. No requests = no units of work = no WorkContexts being created by Orchard.

A workaround would be to inject an IWorkContextAccessor (which is a shell-level component) and create a work context scope manually when you need to (ie. using(var ctx = _wca.CreateWorkContextScope()) { ... }).

[Kumar]

What do you think using HubPipelineModule for creating and disposing workcontext?

https://msdn.microsoft.com/en-us/library/microsoft.aspnet.signalr.hubs.hubpipelinemodule(v=vs.118).aspx