Celery beat scheduler instantiated multiple times

[zroadhouse-rmn]

Affects 3.0.23.

The get_scheduler method is called as part of celery.apps.beat.Beat.startup_info (instead of accessing the beat.scheduler property). This instantiates a scheduler object (lazy=True).

Later, in celery.beat.Service.start() the beat.scheduler property is accessed. Since this is the first call, the scheduler instance is created again (lazy=False).

Is this working as designed?

[ask]

Instantiating the Scheduler class should not have any side effects, so it shouldn't matter that it's instantiated
multiple times.

The lazy argument signifies that the scheduler should not setup the schedule (which causes side effects).
I believe the only possible issue here is if people who write their own scheduler implementations are not aware
of this behavior. I added a note in the docstring about this.

[bmbouter]

I ran into this case today, where the custom Scheduler I was working with was spawning a thread that would enter a blocking read on Receiver.capture(). It's a natural thing to do as part of a custom Scheduler I would imagine. Putting it in the init() of the Scheduler is the most obvious place for that kind of behavior, which resulted in duplicate event processing!

The workaround was to put the thread spawning in the Scheduler.setup_schedule() method, but init() really should only be called once, and the object should be kept around in my opinion. I disagree with the idea that init should not contain side effects assuming you want the side effect with each call to init. I wanted threads created for the Scheduer object created, the problem here is that two Scheduler objects are being made and one of the copies is being thrown away.