Ytukyg

I'm receiving the following error intermittently on one of my SignalR methods:

Error: An unexpected error occurred invoking 'AcceptQueuedUser' on the
server. InvalidOperationException: A second operation started on this
context before a previous operation completed. Any instance members
are not guaranteed to be thread safe.

Anytime I run into this error, the first thing I check is to make sure all my async method invocations are awaited. However, I've gone through my entire code base looking for async methods that are missing an await keyword. I've used regex to try and track it down as well as ReSharper's "Async method invocation without await expression" inspection on the entire solution. No dice.

I have a feeling this problem is related to SignalR, as I've never had this much trouble on normal API Endpoints/Controllers. I'm injecting my scoped DbContext into my SignalR hub as I would on any normal Controller:

 public class ChatQueueHub<TUser> : Hub<IChatQueueHubClient>

        where TUser : class, IChatRoomUser

    {

        private readonly IChatQueueRepository _chatQueueRepository;

        /// <summary>

        /// Default constructor

        /// </summary>

        public ChatQueueHub(IChatQueueRepository chatQueueRepository)

        {

          _chatQueueRepository = chatQueueRepository

        }



        public async Task<ApiResponse<string>> AcceptQueuedUser(int userQueueId)

        {

            // ...

            await _chatQueueRepository.RemoveQueuedUserAsync(userQueueUser);

            // ...

            return new ApiResponse<string>(newChatroom.Id, BaseApiCode.Success);

        }

    }

Here I'm injecting IChatQueueRepository which injects DbContext into itself and performs all context operations.

I have a feeling this is due to some weird threading issue on SignalR, but I can't see anything abnormal in my code. As far as I know SignalR instantiates a new Hub for every RPC sent over the wire.

What are some other things I can look for that would cause A second operation started on this context before a previous operation completed. Any instance members are not guaranteed to be thread safe. aside from non-awaited async invocations?

Edit:

I see now that the ASP.NET Core Dependancy injection documentation says the following:

Entity Framework contexts should be added to the service
container using the scoped lifetime. This is handled automatically
with a call to the AddDbContext method when registering the database
context. Services that use the database context should also use the
scoped lifetime.

SignalR Hubs are Transient, so perhaps this is causing the problem. What is the correct way to access a DBContext from a SignalR Hub?