roflbobl
I have a production system, that queues emails in Oban. It sends the emails with Bamboo.Mailer.deliver_now!/4, but it fails with the error (Bamboo.ApiError) :closed a couple of times, until it succeeds, after 2-5 tries.
We use MailGun to send the emails. I contacted MailGun and they can not see anything wrong on their end, I have no idea where to look anymore.
The “fix” right now, is just to try to rerun the job up until 10 times, with a backoff of 15 seconds.
Anyone who has experienced something similar?
Here is the errror:
Attempt 1—now
** (Bamboo.ApiError) :closed
(bamboo 2.4.0) lib/bamboo/mailer.ex:241: Bamboo.Mailer.deliver_now!/4
(my_app 0.1.0) lib/my_app/workers/send_email.ex:27: MyApp.Workers.SendEmail.perform/1
(oban 2.19.4) lib/oban/queue/executor.ex:145: Oban.Queue.Executor.perform/1
(oban 2.19.4) lib/oban/queue/executor.ex:77: Oban.Queue.Executor.call/1
(elixir 1.18.3) lib/task/supervised.ex:101: Task.Supervised.invoke_mfa/2
(elixir 1.18.3) lib/task/supervised.ex:36: Task.Supervised.reply/4
Where Next?
Trending in Questions
Other Trending Topics
Latest Oban Threads
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #ai
- #phoenix_html
- #iex
- #elixirconf-us
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
ruslandoga
Just a guess: the HTTP connection to Mailgun probably gets closed while in the pool. E.g. because it wasn’t used for a long time. And it probably happens to many connections in that pool, so it takes that many retries to find one that’s still connected.
dimitarvp
I was about to say almost the same as @ruslandoga – try using an HTTP client that does not keep open connections in a pool but always opens them afresh instead (Mint / Finch might be able to do the same with config options as well btw).