Use "recurring jobs" UI for ad-hoc jobs

question
1

It would be really nice to be able to define a recurring job with a “Cron.Never” schedule. This way I can define a job that doesn’t run automatically, but can be scheduled using the “recurring jobs” UI.

This can be used for things that a user might want to only run every once in a while (e.g. clean up folders or something).

On GitHub you already replied:

Hm, it is very interesting scenario, but is very tricky. I understand, when tricky scenarios implemented by tricky methods (for example, using the “* * * * * 2010” expression), but it is hard to me to prove the necessity of its existence in the product itself.

Will you use this feature in your application, if yes, what is the exact use case? Or can you (or you, dear reader of this issue) provide some more arguments?

My use case is that I’m working on a large website where we have lots of small jobs that we run periodically. However, there are a few tasks that we don’t really need to schedule since they only need to be run when some major thing happened. Let’s say we have a client that bulk imported data into our system but they used a wrong parameter. This happens once every month or so. To handle this we’ve created a page where our support staff can start an ad-hoc background task. One of them is to fix this incorrectly uploaded data.

When our support staff clicks this button we can of course enqueue a background job using HangFire. But it would be a separate page (and different UI layout) than we would have for the recurring jobs (because recurring jobs are listed in HangFire). If we can combine it into one page that would be nice, that’s all. :smile:

2

Thanks for the detailed reply! But do you really want to give an access to the internal thing that are built for developers and dev-ops to support staff? They should be very careful in this case, aren’t they?

3

Yes indeed, people will have to be careful. But that’s another issue :smile: And I think user/role management is out of scope for your project, probably.

4

Does this task require any parameter? Because recurring tasks use hard-coded arguments.

5

That would be necessary, yes. I guess this requirement would make it too complex for now.

6

Not so complex, but almost every web app have an administrative page. It is not hard to add yet another button with yet another request handler (or controller action if using asp.net mvc) to enqueue fire-and-forget job. And this implementation is more useful, because it allows to take advantage of coarse grained authorization rules.

7

Yes, that’s right. For now we’ll just keep that page to trigger a regular one-off job, then.