I get the following EOFError fairly often in production. I'm not sure how to reproduce it, but it occurs daily and I was hoping you might have an idea as to why this is occurring.
EOFError: end of file reached
from celluloid/task/fibered.rb:14:in `block in create'
from celluloid/task.rb:44:in `block in initialize'
from celluloid/actor.rb:339:in `block in task'
from celluloid/cell.rb:76:in `block in task'
from celluloid/cell.rb:50:in `block in dispatch'
from celluloid/call/async.rb:7:in `dispatch'
from celluloid/calls.rb:28:in `dispatch'
from celluloid/calls.rb:28:in `public_send'
from sidekiq/processor.rb:50:in `process'
from sidekiq/processor.rb:98:in `stats'
from sidekiq/processor.rb:51:in `block in process'
from sidekiq/middleware/chain.rb:132:in `invoke'
from sidekiq/middleware/chain.rb:132:in `call'
from sidekiq/middleware/chain.rb:129:in `block in invoke'
from sidekiq/middleware/server/logging.rb:7:in `call'
from sidekiq/logging.rb:30:in `with_context'
from sidekiq/middleware/server/logging.rb:11:in `block in call'
from sidekiq/middleware/chain.rb:129:in `block in invoke'
from sidekiq/middleware/server/retry_jobs.rb:74:in `call'
from sidekiq/middleware/chain.rb:129:in `block in invoke'
from new_relic/agent/instrumentation/sidekiq.rb:29:in `call'
from new_relic/agent/instrumentation/controller_instrumentation.rb:362:in `perform_action_with_newrelic_trace'
from new_relic/agent/instrumentation/sidekiq.rb:33:in `block in call'
from sidekiq/middleware/chain.rb:129:in `block in invoke'
from lib/cache/redis_sidekiq_middleware.rb:5:in `call'
from sidekiq/middleware/chain.rb:127:in `block in invoke'
from sidekiq/processor.rb:52:in `block (2 levels) in process'
from sidekiq/processor.rb:75:in `execute_job'
from sidekiq/extensions/action_mailer.rb:21:in `perform'
from sidekiq/extensions/action_mailer.rb:32:in `deliver'
from action_mailer/message_delivery.rb:85:in `deliver_now'
Interesting business name!
That's a bizarre backtrace, it took me a minute to realize it's upside down from typical.
Looks like the remote email server is closing the socket unexpectedly. If you want to ignore this type of error, you'll need to write your own Worker to replace Sidekiq's built-in ActionMailer delay extension.
We run into this from time to time with various SMTP servers. The internet is messy.
@mperham glad you like the name ;-)
Does the built-in ActionMailer retry automatically on these types of failures? If so, I can just ignore these errors.
Yes, by default Sidekiq will retry any job failures, up to 25 times.
Hi @mperham we're experiencing this issue too, and we're getting a lot of noise in our error reporting tool. We don't want to ignore the EOFError application wide, because we only want to ignore/retry in some specific cases.
Rescuing the exception in the perform method won't work:
class MyWorker
def perform
# do something...
rescue EOFError
# do another thing if the error is raised
# THIS WON'T WORK
end
end
Any ideas on how to handle this?
Please don't hijack old issues. Open a new issue with your specifics.
Most helpful comment
Please don't hijack old issues. Open a new issue with your specifics.