Failed emails - RecordNotUnique / RecordInvalid when processing emails from existing users

Technical assistance
1

Used Zammad version: 7.0.1-1777022007.52a7fc39.noble

Used Zammad installation type: package

Operating system: Ubuntu Noble (24.04)

Browser + version: Brave 1.91.168 (Official Build) (64-bit) Chromium: 149.0.7827.54

Infrastructure:

  • Zammad application — dedicated server
  • PostgreSQL 16.14 — dedicated server
  • Elasticsearch 8.19.15 — dedicated server

Expected behavior:

  • When an email arrives from a user that already exists in the database, Zammad should find the existing user and process the email normally, creating a ticket as expected.

Actual behavior:

  • Email ends up in FailedEmail table with one of two errors:
PG::UniqueViolation: duplicate key value violates unique constraint "index_users_on_login"
DETAIL: Key (lower(login::text))=(user@example.com) already exists.

ActiveRecord::RecordInvalid: Validation failed: 
Email address 'user@example.com' is already used for another user., 
Login has already been taken
  • Requires manual cleanup via Rails console each time it occurs.

Steps to reproduce the behavior:

  • Email arrives from a user that already exists in the database
  • Zammad attempts to create the user instead of finding the existing one
  • Email processing fails and lands in FailedEmail table
2

And those users were created how before?
You’re not fiddling directly in Zammads database are you…?

3

Hi, the users were not in the database before this ticket.
And no we are not accesing or doing changes on the DB directly.

I have looked over the documentation, and I will change the setting ZAMMAD_PROCESS_DELAYED_COMMUNICATION_INBOUND_JOBS_WORKERS
this is right now set to 3, and I am suspecting on this to be the problem.
Even if this is the problem, why would the system still look for the ticketing creation process if the ticket has been created.

4

That might be a good catch. How many email accounts to you have connected?

Might be a race condition. Shouldn’t happen, but who knows. Kinda might depend on the answer of my above question. I did test this feature during my 7.0 release video, but with a fitting amount of email channels and didn’t have problems.

That being said, it doesn’t mean there might be no problem.

5

Right now we are on 16 emails integrated with IMAP in the system.

Priror to this problem we didn’t have problems when the setting was set to 3 workers. I changed the setting to 1, and we are not having any issues so far. weekly we would get 10-15 failed emails before change.
We didn’t touch the database directly, also to avoid any kind of DB optimization we transferd to storage to Filesystem, since we get around 700-900 tickets daily.