Auto stopping scheduler when all jobs are done

[husam-e]

I've noticed that the scheduler continues to run even when all jobs on it are completed and removed. This is probably intentional to support adding jobs at any point after the scheduler is created, as opposed to only before it is started?

Wondering if it would be possible to set the scheduler to stop when all its jobs complete?

This would help in testing where we can set a limited number of runs, let the scheduler operate as usual, then have it complete, and then do our assertions.

It can also help in production scenarios where you want a limited number of runs and then the process to complete without having to poll and manually stop the scheduler.

Lmk if there's already a way to do this I haven't found.

[JohnRoesler]

Hi @husam-e,

I've noticed that the scheduler continues to run even when all jobs on it are completed and removed. This is probably intentional to support adding jobs at any point after the scheduler is created, as opposed to only before it is started?

Exactly, it's intentional to allow for adding jobs at the start and adding additional ones at any time.

Wondering if it would be possible to set the scheduler to stop when all its jobs complete?

It would be possible, but I see a lot of potential issues with it and knowing exactly when it's ok to shut the scheduler down.

Instead, I would suggest looking through the tests in the gocron repo. I've tried out a few different strategies for knowing when to shut down the scheduler - sometimes having a channel that the job sends a "i ran" message to, sometimes waiting an amount of time after which I know my jobs will have completed. Probably other ways to do it. After i've reached the trigger for jobs being done, then I shutdown the scheduler and perform assertions.

I'd be happy to help brainstorm solutions if you want to share code 👍

[husam-e]

Hey @JohnRoesler, thanks for the suggestions and timely response!

I need a "black box" way to test the job, as I can't modify it to do something extra for my test, and I didn't want to purely rely on time as that can be non deterministic since I don't know how long each job run will take.

You motivated me to find another way that just requires control of the Scheduler which I'm injecting into the test, using event listeners where I push to a buffered channel in an after job run listener, then wait by pulling from the channel the number of times I expect the job to run. This seems reliable and is working.

Cheers!