Feature Request: Provide a means of directly cancelling a running job (by id) without having to delete it

[bhehe]

I've been writing some integration tests and when it came time to explore how to recreate/mimic the cancellation support, I wasn't finding a way to simply cancel a single specific job that is running. In my case I'm working with recurring Jobs and I would have the JobId available to me now that TriggerExecution(jobName) returns it and we've aligned to use that method now.

On researching the issues here, it seems like the only option is (a) delete the job and (b) wait for the background monitoring process to note that it was deleted and then that would trigger the cancellation token.

In my case, we'd really like to not have to delete the job as that's not our real intent - we just want to simply cancel it. When we trigger that cancellation, it would ideally be nearly instant - without some long waiting period in between. I'm not sure if there's a way to configure how long that background process waits between its polling/checks so perhaps there's a way to address that as when we're running our tests we're using the in-memory storage provider so frequent polling wouldn't be an issue.

I'm also a bit unclear of the 'official' or 'right' way to find the Job/Delete it, etc. I need to go back & re-read the various related posts I've browsed and see which one feels like the correct approach.

What would be really handy is just a simple method for cancellation like we have for other similar needs. i.e. bool BackgroundJobs.Cancel(jobId) or something similar. Perhaps a boolean result would be insufficient to reflect the potential outcomes but the key thing I'm looking for is that it returns a result value that indicates if the job was indeed cancelled (or other potential outcomes that may occur - i.e. if the job already completed before it could be cancelled, job did not exist, etc.)

[aviatrix]

I'm also in need of such a feature. Sometimes i just want to stop the job, then re-start it in a bit, but not delete it.

[odinserj]

BackgroundJob.Delete method doesn't delete the job instantly. Instead, it moves it to the Deleted state, and it will be in the storage for some more time (default 24 hours for regular jobs and 7 days for batched jobs), until expired. These defaults can be configured, please see https://discuss.hangfire.io/t/how-to-configure-the-retention-time-of-job/34/2?u=odinserj for details.

[brgrz]

Ability to cancel a scheduled job would also benefit me and one other thing - the ability to provide custom expiration time to both Enqueue and Schedule. The use case is this: a job might be scheduled but for some reason Hangfire server is unavailable at the time of schedule. When server becomes available we might not want anymore for the job to run - it is currently happening that old, expired jobs are being processed.

We are currently handling this by providing expireAt parameter to our jobs but it'd be better if this was available through the Hangfire api.