monitor.go:128 was logging after some tests had returned, which Go catches and helpfully panics for us. The logged error indicates context cancellation, which we can check for, and if that's the case just return.
If getScheduledCommandJobs returns errors repeatedly, then the continue makes the loop busy because getScheduledCommandJobs is called at the top. So I relocated the select to the top. To preserve getScheduledCommandJobs being called right away in the first iteration, there's a channel that can be read immediately on the first iteration.
Because there is now more than one return in the goroutine that is not also below a send on errs, I've also made close(errs) deferred in the goroutine.
monitor.go:128 was logging after some tests had returned, which Go catches and helpfully panics for us. The logged error indicates context cancellation, which we can check for, and if that's the case just return.
If
getScheduledCommandJobsreturns errors repeatedly, then thecontinuemakes the loop busy becausegetScheduledCommandJobsis called at the top. So I relocated theselectto the top. To preservegetScheduledCommandJobsbeing called right away in the first iteration, there's a channel that can be read immediately on the first iteration.Because there is now more than one
returnin the goroutine that is not also below a send onerrs, I've also madeclose(errs)deferred in the goroutine.