DisposedExecption occurs injecting about coravel HOT 7 CLOSED

I created this solution for now which appears to work, by adding the scoped using as part of the task it builds up a valid scope that is in the context of the call:

_queue.QueueAsyncTask(async () =>
            {
                using (var scope = _scopeFactory.CreateScope())
                {
                    var task = scope.ServiceProvider.GetService<MigrationCreateTask>() as MigrationCreateTask;
                    task.Initialise(request.Name, request.EnvironmentUrl, request.WhitelistPrefix);
                    await task.Invoke();
                }
            });

Thoughts on this solution? Is this what you would recommend?

It just means there is no way to use the other methods on queue like

            _queue.QueueInvocable<MigrationCreateTask>();

As this would fail both because the scope would not be valid and I can't call Initialise .

from coravel.

Hmmm, are your invocables configured as scoped or transient in the DI config?

from coravel.

Using _queue.QueueInvocable<MigrationCreateTask>();, under the covers, does something akin to your temporary solution. At face value, I'm not sure what's going on. I'll see if I can try to replicate something like this and do a little test.

from coravel.

The invocable is transient. Without the scope of the controller request, I see the need for the new scope surrounding the task. Since DbContexts normally use the scoped lifetime, since the controller request exits with an OK response, the scope will be disposed and since the task is queue for 30 seconds before being started, then the DbContext will be disposed too.
That is my assumption anyway, I could be wrong hence the question.

Full code for the controller method. Code was confirmed with your QueueWithCancellationTokens sample.

        [HttpPost]
        public IActionResult CreateMigration([FromBody]MigrationCreateRequest request)
        {
            if (request == null)
                return BadRequest($"Missing the create {DisplayName} request body.");

            var newGuid = Guid.NewGuid();
            var newToken = new CancellationTokenSource();

            _tokens.TryAdd(newGuid, newToken);
            _queue.QueueAsyncTask(async () =>
            {
                using (var scope = _scopeFactory.CreateScope())
                {
                    var invocable = scope.ServiceProvider.GetService<MigrationCreateTask>() as MigrationCreateTask;
                    invocable.Initialise(request.Name, request.EnvironmentUrl, request.WhitelistPrefix);
                    await invocable.Invoke();
                }
            });
            return Json(newGuid);
        }

I'm actually happy for this to be closed as the code is working really well now.

from coravel.

Calling _queue.QueueInvocable<MigrationCreateTask>(); should work. Under the covers, that method will create a new scope so it's not tied to the HTTP request/scope at all....🤔

Also, if you do use QueueInvocable then you won't be able to call the custom method you made invocable.Initialise(). If that method is required (which surely seems it is) then manually creating the scope as you did will work.

However, in cases where you want to queue something in the background yet be able to pass certain parameters to the invocable, it might be worth looking at the event broadcasting feature of coravel.

You could create an event CreateMigration or whatever with an event listener (instead of an invocable).

https://github.com/jamesmh/coravel/blob/master/Docs/Queuing.md#queue-event-broadcasting

from coravel.

I added an EF Core sample (really simple) to the repo: https://github.com/jamesmh/coravel/tree/master/Samples/EFCoreSample

It works as expected, so there must be something unique about your project that's causing the EF Core DB context to behave like it is?

from coravel.

Thank you. Like you said, "that method will create a new scope" is the key, because I can't use 'QueueInvocable' due to initialization then yes I had to add the scope myself.
I am looking into the event broadcasting as an alternate and it's looking very promising. Thanks for this suggestion. Learning someone else component is always better than writing your own.

from coravel.