-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include Entry as function parameter #153
Comments
Totally agree. Including context of the execution is definitely going to help in a couple scenarios. |
I agree that it seems useful, but I can't see any way to add this functionality in a backwards compatible manner. Or even if it weren't backwards compatible, I don't think that I'd want to force all jobs added to cron to accept that parameter. Do you have any ideas how to solve this? |
A related idea is providing a context to jobs which provides that sort of information in it, and which can be used for cancelation (e.g. calling cron.Stop() cancels the context passed to all jobs). A context is something which seems ok to require all jobs to accept, or perhaps a ScheduleContext / AddContext similar to how the stdlib was retrofitted |
Hi, I just started using this library and came here to say that it would be really helpful to have a context passed as a parameter, for this exact reason! My use-case is that I have longer running jobs that I need to stop rather than wait on when my application exits (it would take too long to wait for them to finish). Passing a context to the job function would allow me to cleanly finish the job after it has been requested to stop, and would also allow entryID, time, etc to be passed as values on the context. Perhaps this could be implemented by adding a new method: @robfig Please let me know if this sounds close to what you were thinking, I'd be happy to implement it if you'd like. |
Yeah, this seems like a good change, although I wouldn't use the term Cancelable since jobs may want the context just to get the schedule information. Maybe something boring like AddJobContext / type ContextJob interface |
It would be great if the job function retrieves the respective entry as parameter to get schedule information.
This would enable a job to get the time interval and previous execution time.
In my case I need the time of the previous execution.
Storing
time.Now()
may be suitable in some situations, but might lead to some missing milliseconds. ;-)The text was updated successfully, but these errors were encountered: