Support for cancellable invocables

[Blinke]

Thank you for your contribution! Before submitting this PR, please make sure:

• [x] If you are fixing something other than a typo, please always create an issue first. Otherwise, your PR will probably be rejected
• [x] Your addition is not too large. The more files/lOC changed means the longer it'll take to be addressed by me (the maintainer)
• [x] Your code builds clean without any errors or warnings
• [ ] You have added user documentation for any additional features
• [x] You have added unit tests which (a) pass and (b) sufficiently cover your changes

Other Notes:

Coravel is created with a specific vision and philosophy:

• Simple, fluent and straightforward public APIs
• Easy to read documentation that guides users coherently
• Building useful features because they really are useful - not just for the sake of adding "more features"

To that effect, don't feel bad when many changes are asked of your PR 😉

---

Implementation for #133

As far as I can tell, the cancellation token passed to IHostedService.StartAsync is only used to cancel the startup process and does not get triggered on shutdown. Instead I created one in the scheduler and trigger the cancellation manually on shutdown before waiting for all the tasks to finish.

I haven't tackled updating the documentation yet. Let me know if you'd like me to or if you'll write it up yourself.

[jamesmh]

Awesome work! Love it. I'll add some docs after the merge.

[Blinke]

Great! I've used Coravel for multiple projects at work so it feels good to be able to make some contributions even if they are pretty small 😊

[jamesmh]

Nice! So far I think you've contributed the most features other than myself 😄

I'd love to hear about what kind of projects you're using Coravel for too 👍

[Blinke]

We're using it for some pretty simple stuff right now, just running scripts on different intervals to verify data from an unreliable legacy system and send notifications when anomalies are found. We have a similar service running as a Kubernetes cronjob that we will also move to Coravel soon.

Then we have a pretty complex data scraping/caching service that I would like to move from Hangfire to Coravel since we don't have any need for persistence or distributed schedulers 🙂

[jamesmh]

That's some pretty cool stuff. Are there any specific benefits you've found between Hangfire vs. Coravel? I know Coravel is (probably) easier to get started with, seems to have a simpler API and has full async. Any other considerations that make you want to move over?

Have you run into any issues or blockers for perhaps more complex uses? I've got some ideas to make Coravel easier/more compatible with microservices and more complex project configurations. Wondering if there are any other things that real-usage has revealed (to you)?

[Blinke]

The simplicity is the main reason for wanting to move over at this point. Hangfire has a lot bells and whistles that are really nice if you actually need them. Turns out that we don't, for the most part. It works just fine but it's a bit overkill for our application and adds unnecessary complexity.

We also kept encountering issues the first couple of months of using Hangfire that were not always straightforward to troubleshoot. I'm sure a lot of it was user error and just not knowing how to do things properly but it was still a bit of a roadblock for us. Setting up Coravel, on the other hand, is really hard to get wrong.

Something I do miss in Coravel that Hangfire supports is being able to limit how many queued jobs can execute at once. Having named queues with different configurations is also a plus.

Our scrape service runs some checks every 15 minutes and then queues up one or more jobs if there is new data available. These jobs can take anywhere between 5 and 20 minutes each and most of the time is spent making HTTP requests and waiting for responses. For a more steady throughput and to not overload the API we consume, the queue only processes a few jobs at a time instead of all of them at once.

[schmitch]

btw. my company basically can support all use cases with coravel that we used in hangfire with this PR. so really thanks @Blinke. the only thing is the dashboard that is only usable in coravel pro and schedules (with parameters) that are stored inside the database (but we can't upgrade to 1.7.x since something is broken in Hangfire), so our plan is to dismiss database scheduling (since it was just a goody) and stick with coravel.

edit: oh and limiting how many queued jobs can execute at once is also one downside that we encountered, but not a big deal since we can easily disable queuing up new tasks, if a task is still running. (i.e. we only allow 1 queued task per invocable)

[jamesmh]

Awesome 👍 That's some helpful feedback.

@Blinke - you bring up some areas that others have brought up in other issues:

• Multiple queues (my thinking is even to fully configure them via the appsettings file + a fluent API
• Queue job execution limit (doing this per queue would be really nice)

[Blinke]

@schmitch - Nice, I'm glad to hear that!

@jamesmh - Great to hear the feedback was useful 🙂 I've been having a really good time working on this so project so far, hopefully I can continue to contribute on the new issues.