Email Processing Fails with Timeout::Error: execution expired (Zammad 7.1.3)

Technical assistance
1

Hi everyone, good day!

Environment

  • Zammad version: 7.1.3

  • Installation type: Package

  • Operating system: Ubuntu

  • Elasticsearch version: 8.19.20

  • Browsers: Chrome and Firefox

Issue Description

We encountered an issue where an email could not be processed. The error report shows Timeout::Error: execution expired.

When checking the failed email using the following command:

zammad run rails r 'FailedEmail.all.each { |f| puts "#{f.id} | retries=#{f.retries} | #{f.parsing_error}" }'

We received the following output:

4 | retries=1 | #<Timeout::Error: execution expired>
/opt/zammad/vendor/bundle/ruby/3.4.0/gems/timeout-0.6.1/lib/timeout.rb:40:in 'Timeout::Error.handle_timeout'
/opt/zammad/vendor/bundle/ruby/3.4.0/gems/timeout-0.6.1/lib/timeout.rb:306:in 'Timeout.timeout'
/opt/zammad/app/models/channel/email_parser.rb:152:in 'Channel::EmailParser#process_with_timeout'
/opt/zammad/app/models/channel/email_parser.rb:132:in 'Channel::EmailParser#process'

Investigation So Far

  • Server status: No downtime observed.

  • Email size: 25.42 MB, within our configured 30 MB limit.

  • Reprocessing: Reprocessing the failed email works fine.

  • Error message: Timeout::Error: execution expired.

As part of our investigation, I went through existing forum posts and checked the 0015_postmaster_filter_identify_session_user setting. It is present in our system, with both the current and initial values set to Channel::Filter::IdentifySessionUser:

{
  "name": "0015_postmaster_filter_identify_session_user",
  "current_value": "Channel::Filter::IdentifySessionUser",
  "initial_value": "Channel::Filter::IdentifySessionUser"
}

Questions

Has anyone encountered a similar issue in version 7.1.3?

Since the email can be processed successfully when reprocessed, and there was no server downtime, we would appreciate any suggestions on what might cause the initial processing to time out.

Are there any additional logs, configurations, or known issues we should investigate to identify the root cause?

Any suggestions or insights would be greatly appreciated. Thank you!

2

A 25 MB mail is the likely trigger. The parser runs inside a fixed timeout, and big attachments (many inline images, or a large PDF that gets text extracted for Elasticsearch) can push one run past it when the server is busy. Reprocessing then passes because the load is lower.

Worth checking:

1. Was a backup, scheduled job or ES reindex running at the failure time? Compare the timestamp with cron and production.log.

2. Was CPU or RAM maxed, and how many background workers do you run?

3. If huge mails are common, lower the max mail size a bit or ask senders to share big files as links.

Since reprocessing works, a small cron that retries failed emails is a fine stopgap, but finding the load spike is the real fix.