Race condition in DI scheduler listener initialization

[esskar]

Describe the bug

I implemented my custom ISchedulerListener - it does nothing, just return Task.CompletedTask for now. I register it in DI c.AddSchedulerListener<MySchedulerListener>();
Constructor is called during startup, when I schedule a job

class MyService
{

    public async Task CreateJobAsync()
    {
        var job = JobBuilder.Create<ProcessJob>()
            .WithIdentity("foo")
            .Build();
    
        var trigger = TriggerBuilder.Create()
            .WithIdentity("bar")
            .StartNow()
            .Build();

         var scheduler = await StdSchedulerFactory.GetDefaultScheduler();
         var scheduled = await scheduler.ScheduleJob(job, trigger);
    }
}

No function of my MySchedulerListener is triggered.

Then, I tried using ISchedulerFactory via DI

class MyService
{
    private readonly ISchedulerFactory _schedulerFactory;

    public MyService(ISchedulerFactory schedulerFactory)
    {
        _schedulerFactory = schedulerFactory ?? throw new ArgumentNullException(nameof(schedulerFactory));
    }

    public async Task CreateJobAsync()
    {
        var job = JobBuilder.Create<ProcessJob>()
            .WithIdentity("foo")
            .Build();
    
        var trigger = TriggerBuilder.Create()
            .WithIdentity("bar")
            .StartNow()
            .Build();

         var scheduler = await _schedulerFactory.GetScheduler();
         var scheduled = await scheduler.ScheduleJob(job, trigger);
    }
}

Now, the constructor of MySchedulerListener is called a second time when I call _schedulerFactory.GetScheduler(); and the functions of MySchedulerListener are called twice.

Version used

3.2.4 and using .NET 5.0

Expected behavior

From looking at the code, I understand that StdSchedulerFactory.GetDefaultScheduler() will not work as - internally - it is not using any DI, but I expected that ISchedulerFactory would only trigger my MySchedulerListener once.

[lahma]

One shouldn't mix and max "regular" scheduler building and DI, like you've noticed. Such double invocation could be a result of race condition in scheduler initialization (two threads calling schedulerFactor.GetScheduler() at the same time). I've added synchronization primitive to prevent that.