[BUG] - Scheduler started with WithLimitConcurrentJobs with WithLimitWait does not run a OneOffJob since 2.2.5

[daviesluke]

Describe the bug

When creating the scheduler with the options WithLimitConcurrentJobs with WithLimitWait mode does not run any jobs scheduled as a One off job -> OneTimeJob(OneTimeJobStartImmediately())

Works using version 2.2.4 - but fails in 2.2.5 and 2.2.6

To Reproduce

Steps to reproduce the behavior:

Here's the program to test

package main

import (
        "fmt"
        "time"

        "github.com/go-co-op/gocron/v2"
)

func runJob() {
        fmt.Printf("Job run\n")
}

func main() {
        fmt.Println("Creating the scheduler")

        newSched, _ := gocron.NewScheduler(
                gocron.WithLimitConcurrentJobs(
                        1,
                        gocron.LimitModeWait,
                ),
        )

        job, _ := newSched.NewJob(
                gocron.OneTimeJob(gocron.OneTimeJobStartImmediately()),
                gocron.NewTask(runJob),
                gocron.WithLimitedRuns(1),
        )

        fmt.Printf("Job %s created\n", job.ID())

        newSched.Start()

        fmt.Println("Scheduler Started")

        for len(newSched.Jobs()) > 0 {
                time.Sleep(100 * time.Millisecond)
        }

        fmt.Println("Scheduler Stopping")
        newSched.Shutdown()
}

Output using 2.2.4

Creating the scheduler
Job 63928672-148f-4499-bef6-90da20b9a806 created
Scheduler Started
Job run
Scheduler Stopping

Output using 2.2.6

Creating the scheduler
Job 316db4e1-6fab-4e21-8e9e-dcb29e5ec647 created
Scheduler Started
Scheduler Stopping

Version

2.2.4 - Working
2.2.5 - Not working
2.2.6 - Not working

Expected behavior

Expected to run the job scheduled

Additional context

None

[JohnRoesler]

Hey @daviesluke thanks for reporting.

Ok, so the issue is that in order to solve a different case, in the limit mode wait, I'm triggering the executor to send back to the scheduler so another job can be scheduled. The assumption being that you're using a limit mode because jobs run a long time or are intensive and so you don't want them to overrun each other.

What's actually happening now this case you provided, is that the job is being sent to the wait mode limiter and before it has a chance to run, it's being removed by the scheduler because it thinks the job has run already and reached it's limit.

Since you're running a one off job, there is really no reason to use gocron.WithLimitConcurrentJobs or even gocron.WithLimitedRuns(1) as gocron.OneTimeJob will only ever run the job once.

Curious to understand more about your scenario if you can provide further details on it.

I'll do some digging into how the code may be refactored to handle this case better.

[daviesluke]

I am using the the gocron functionality to run a monitoring daemon which runs configured checks. Normally this runs jobs (checking scripts) based on the schedules provided and in this case one-off jobs are not normally needed. However the users sometimes want to test that a check script is now running normally or do some other testing. By providing an --once option these jobs are scheduled via the new OneTimeJob functionality, but the scheduler is started using the same mechanisms as before, and the jobs are run just once before exiting the scheduler. It may be that just one job is being asked to run or it may be a whole suite of checks are requested to be run in this --once mode.
The reason I wanted to use the gocron.LimitModeWait is so that jobs do not miss their scheduled time if there are many other jobs running at their designated start time as their schedule may be just once a day and missing the daily run would not be a good option.
I suppose a work-around might be to turn off gocron.LimitModeWait if using this --once option but wonder if this may cause issues if I were to say schedule 10 OneTimeJob tasks but with a gocron.WithLimitConcurrentJobs limit of say 2 threads. Would this cause 8 jobs to just not run - I would have to test this.