Scoped dependency injection in a scheduled task

2025/03/19 10:02 PM

I'm trying to write a scheduled task that makes use of several of the repositories and services we've defined in our Xperience solution. I was happy to see that XByK allows injection into schedule task classes unlike K13.

The problem I'm having is that most of these services are registered with a scoped lifetime since they make use of Xperience system services that are also scoped. That's a problem here because the scheduled tasks don't run in a scoped context. All of my service calls fail:

Cannot resolve scoped service '[ServiceType]' from root provider.

Now we can inject an IServiceProvider into our task, call CreateScope, and call GetRequiredService on that for our dependencies, but that makes testing hard. We could move the logic of the task into another class and call GetRequiredService for that class as well, but it seems like tasks should just run in their own DI scope.

Is there any reason scheduled tasks aren't run in a DI scope? Or any way to override this default?

Environment

Answers

2025/03/19 10:28 PM
Accepted answer

since they make use of Xperience system services that are also scoped.

All of Xperience's services are registered as singleton or transient - so if you are using Scope services that's because your application needs it, not because you are injecting scoped dependencies from Xperience.

That's a problem here because the scheduled tasks don't run in a scoped context.

Like you mentioned, you can always generate your own scope if you really need one. You lose the benefit of constructor injection into the scheduled task, but you can then handle any scoped services you need.

public class HelloScheduledTask : IScheduledTask
{
    private readonly IServiceProvider provider;

    public HelloScheduledTask(IServiceProvider provider)
    {
        this.provider = provider;
    }

    // Called by the system when running the scheduled task.
    public Task<ScheduledTaskExecutionResult> Execute(ScheduledTaskConfigurationInfo task, CancellationToken cancellationToken)
    {
        using var scope = provider.CreateScope();

        var service = scope.ServiceProvider.GetRequiredService<MyScopedService>();

        // use your service

        return Task.FromResult(ScheduledTaskExecutionResult.Success);
    }
}

but it seems like tasks should just run in their own DI scope.

Scheduled tasks are managed by an CMS.DataEngine.ApplicationBackgroundService, so it should be possible to have it generate a new scope for each task execution. I'm guessing we didn't do this because it was a much simpler solution to instantiate the scheduled tasks as transient and not have to handle creating/disposing of scopes.

If you want to share your use-cases you can give us some feedback on the roadmap.

2025/03/19 11:29 PM

Thanks for the insight. I guess I should've said that I assumed Xperience services were scoped.

In this particular case, the repository in question is part of a third-party library. That library, though, only uses Xperience system services itself, so I'll raise the issue with the author and see if they can change their own registration code.

To response this discussion, you have to login first.