Include Entry as function parameter

[daviian]

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. ;-)

[mewa]

Totally agree. Including context of the execution is definitely going to help in a couple scenarios.

[robfig]

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?

[robfig]

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

[bmon]

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: Cron.AddCancelableFunc, which requires the function supplied to accept a context. You could add a CancelableFuncJob type, and then during Cron.Stop() or Cron.Remove(), cancel the context.

@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.

[robfig]

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