Ability to provide id and delete for everything about jobrunr

[cemremengu]

You may be correct with that intituition since I am currently using redisson and it has no way of providing custom id as well (even for recurring tasks) so I guess it is users responsibility to keep track of those or linking meaningful names instead of the system. Feel free to close the issue whenever you need.

[cemremengu]

By the way, if you agree to these changes I can send a PR for any of the enhancement issues I create. Just let me know please.

[rdehuyss]

I'm happy to foresee a delete api.

But I don't see the need for specifying a custom id. Is there a reason why you need it?

[cemremengu]

I wanted it so that deleting is easier if we could assign a label to jobs. Otherwise, you have to somehow do a book keeping of the jobids. Is there a way to know which jobid belongs to which job when deleting?

[rdehuyss]

FYI, the delete api is progressing but was really difficult - take for example a long-running job that you want to delete (so it is already processing) when you delete it: I'm now interrupting the Thread so that the processing is cancelled and the job is stopped (even if it has not completed yet).

Regarding the book keeping of jobids - I don't understand your question: "Is there a way to know which jobid belongs to which job when deleting?"

For recurring jobs it makes sense to delete by a custom id that you can provide. But why do you need it for a normal enqueued job? Normally, if you enqueue a standard job and the queue is empty, it will be processed immediately - why would you delete it after enqueueing it?

Perhaps some extra business context can help me understand your exact problem?

[cemremengu]

Thanks for the improvements, I really would like to contribute as well once I have time too.

Maybe I am overthinking and wrong but cant you have a delayed task that will run 5 hours later? In that case you may want to cancel. Say that you schedule to send an email if you dont receive a particular event in 5 hours. Once you receive the event, you cancel the delayed job. Here you can link the job and event name so that it is easier to match.

Also for deleting, some users may want a graceful option (i.e. wait currently running instance to finish)

[rdehuyss]

I can understand the business scenario but I don't know yet if providing the id for the job is the way to go.

I think it can result in a lot of other issues (what when you have more than one job for the same business concept, what if you enqueue 2 totally different jobs with the same id, ... ).

I'll look if I cannot find another solution that solves the problem...

[rdehuyss]

Closing as ok with original poster