I’m going to chime in that I’ve got a need for Oban.delete/1 as well, or the ability to delete by job args. I’m going to just use normal Repo.delete/2 to try and remove the job before it runs.
brentjanderson
sorentwo
Oban Core Team
There isn’t an issue for adding Oban.delete/1 so it hasn’t been on my radar. If it is something you’d like to see please open an issue. Otherwise, it is perfectly fine to use Repo.delete/2 to delete jobs, they are just ecto structs.
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
Perhaps the right move would be to create some concrete examples or guides. If people should feel comfortable manipulating the Oban.Job structs as ordinary ecto schemas, some official guides or examples will go a long way towards creating that comfort I think.
@sorentwo However this does raise a question: What happens if a job is deleted while the job is in progress? This is perhaps an area where some Oban functions, whether they are query helpers or full functions come in handy. Specifically, users may want to say “delete this job which I think is still pending, but if in fact it has already started to run, don’t delete it, BUT also don’t retry it if it fails”. I know enough about how Oban works that I’m pretty sure I could write the ecto query to make that sort of thing happen, but it is I think slightly more complicated than just calling Repo.delete.
sorentwo
Oban Core Team
You’re telling me! Some guides are toward the top of my list of things to work on. Writing takes even more time than coding.
That would cause a little trouble. There would be an error when the executor goes to update the function. The backoff wrapper would attempt it several more times before finally raising an error and crashing the parent task. After that the job would be gone, so that would be the end of it.
I think that is a good argument in favor of providing an Oban.delete function. It reduces the amount of internal knowledge required to gracefully handle “safe” job deletion. Combined with some docs that explain how to use Ecto to query the jobs table that would provide a complete solution.
smolcatgirl
Hi, I am unsure about something. Are jobs marked as discarded only after they have been retried all the possible times?
Thanks
sorentwo
Oban Core Team
Yes, that is how the flow works currently. Jobs are discarded when they have exhausted all retries. The only other official way, currently, is to discard through the UI.
There is a PR in progress to add a discard function and another that supports returning a :discard tuple from perform/2
thojanssens1
Hello, I just came across Oban, and I don’t know much about it yet, but I have already a few questions.
I will use Bamboo or Swoosh to send out emails. Bamboo for example allows to send emails in background:
But I see that it doesn’t use Oban. Is delivering emails in background not a good use case for Oban? Swoosh doesn’t have a built-in mechanism to send in background, but simply mentions Task.start/1, without mentioning Oban. Is Oban overkill for these operations? When do I typically want to use Oban?
Other question is, what are the DB triggers actually for? Can someone explain in layman’s terms 
? I know that a trigger allows to execute code after a DB operation, but why use that?
smaximov
I think that’s because deliver_later appeared in Bamboo long before Oban was created.
It’s a perfect use-case for Oban. Personally, I use Oban to compose and deliver emails in background with Swoosh.
LostKobrakai
It is, but also not everyone is using or wants to use Oban, so those libraries either come with their own async api or propose elixir core options.