Open pcfreak30 opened 4 months ago
@pcfreak30 I can see the value in these features beyond your use. Happy to review a PR. The diff you have looks pretty straightforward, just some comments and such needed 👍
One thing came to mind, would the startedChan
be better off as some sort of callback for a "before start" as a job option?
as it stands I think it would need to be a go routine anyways to not block. but my case always uses it ATM.
Thoughts?
Good point, could do away with startedChan
as you can just use the existing https://pkg.go.dev/github.com/go-co-op/gocron/v2#BeforeJobRuns event listener
@JohnRoesler i have created 2 prs that should sum up everything
I believe this would need to be several PR's, but I want feedback on if they should be refactored upstream, the best approach?
https://github.com/go-co-op/gocron/compare/v2...LumeWeb:gocron:expose_started_locker
Summary of changes:
In
executor.go
:jobOutUpdateLockRequest
to the executor struct.startedChan
when a job begins execution.In
job.go
:lastLock
to the job struct to store the most recent lock.startedChan
channel to the job struct.Started()
: Returns thestartedChan
.Lock()
: Returns thelastLock
.Context()
: Returns the job's context.In
scheduler.go
:jobOutUpdateLockRequest
for lock update requests.jobOutUpdateLockRequest
to handle these requests.jobOutUpdateLockRequest
to process lock updates.Updated the job initialization process to create the
startedChan
.In summary
Add to
Job
interface method to get the active context. I use this to abort a monitor thread if the job is canceledAdd ability to get the active
Lock
if it exists which requires new channel comms betweenscheduler
andexecuter
. I use this to managing the lock directly outside cron library.Add a new
startedChan
andStarted
that flags when a task has begun but before the task function is called. I use this for a monitor to wait until the task is actually started.@JohnRoesler