'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:139:in 'block (4 levels) in Sidekiq::Processor#dispatch'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:281:in 'Sidekiq::Processor#stats'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:134:in 'block (3 levels) in Sidekiq::Processor#dispatch'
> sidekiq-7.3.10/lib/sidekiq/job_logger.rb:15:in 'Sidekiq::JobLogger#call'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:133:in 'block (2 levels) in Sidekiq::Processor#dispatch'
> sidekiq-7.3.10/lib/sidekiq/job_retry.rb:85:in 'Sidekiq::JobRetry#global'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:132:in 'block in Sidekiq::Processor#dispatch'
> sidekiq-7.3.10/lib/sidekiq/job_logger.rb:40:in 'Sidekiq::JobLogger#prepare'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:131:in 'Sidekiq::Processor#dispatch'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:183:in 'block (2 levels) in Sidekiq::Processor#process'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:182:in 'Thread.handle_interrupt'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:182:in 'block in Sidekiq::Processor#process'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:181:in 'Thread.handle_interrupt'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:181:in 'Sidekiq::Processor#process'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:86:in 'Sidekiq::Processor#process_one'
> sidekiq-7.3.10/lib/sidekiq/processor.rb:76:in 'Sidekiq::Processor#run'
> sidekiq-7.3.10/lib/sidekiq/component.rb:10:in 'Sidekiq::Component#watchdog'
> sidekiq-7.3.10/lib/sidekiq/component.rb:19:in 'block in Sidekiq::Component#safe_thread'
>
> ```
> **info**
>
> ```plaintext
> Unrecognized error type (ActiveRecord::Deadlocked: PG::TRDeadlockDetected: ERROR: deadlock detected
> DETAIL: Process 1170678 waits for ShareLock on transaction 3318690; blocked by process 1170676.
> Process 1170676 waits for ShareLock on transaction 3318694; blocked by process 1169876.
> Process 1169876 waits for ExclusiveLock on tuple (4,27) of relation 74547 of database 16384; blocked by process 1170678.
> HINT: See server log for query details.
> CONTEXT: while locking tuple (4,27) in relation "categories"
> ) when processing incoming email
>
> Backtrace:
> /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/rack-mini-profiler-4.0.1/lib/patches/db/pg/alias_method.rb:109:in 'PG::Connection#exec'
> /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/rack-mini-profiler-4.0.1/lib/patches/db/pg/alias_method.rb:109:in 'PG::Connection#async_exec'
> /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/activerecord-8.0.5/lib/active_record/connection_adapters/postgresql/database_statements.rb:167:in 'ActiveRecord::ConnectionAdapters::PostgreSQL::DatabaseStatements#perform_query'
> /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/activerecord-8.0.5/lib/active_record/connection_adapters/abstract/database_statements.rb:556:in 'block (2 levels) in ActiveRecord::ConnectionAdapters::DatabaseStatements#raw_execute'
> /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/activerecord-8.0.5/lib/active_record/connection_adapters/abstract_adapter.rb:1022:in 'block in ActiveRecord::ConnectionAdapters::AbstractAdapter#with_raw_connection'
> /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/activesupport-8.0.5/lib/active_support/concurrency/null_lock.rb:9:in 'ActiveSupport::Concurrency::NullLock#synchronize'
> /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/activerecord-8.0.5/lib/active_record/connection_adapters/abstract_adapter.rb:991:in 'ActiveRecord::ConnectionAdapters::AbstractAdapter#with_raw_connection'
> /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/activerecord-8.0.5/lib/active_record/connection_ada...
>
> ```
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [April 7, 2026, 9:37pm UTC](https://meta.discourse.org/t/2-emails-rejected-by-2026-4-0-latest-5f0d95e1f1/400152/3 "2026-04-07T21:37:29Z")
Hi, thanks for taking a look - I want to make sure I gather the _right_ additional data before running anything noisy on the server.
Based on the deadlock and how `Jobs::ProcessEmail` runs, I’m thinking the following might help narrow this down, but I’d appreciate confirmation before I proceed.
* * *
### 1. Email header comparison (failed vs successful)
I can extract and post **redacted raw headers** from:
- `/admin/email/received` → “Show original”
For:
- 1 failed email
or both as per
> [@Ethsim2](#):
>
> redacted headers for the 2 rejected emails
- 1 successful email of the same pattern
as per
> [@Ethsim2](#):
>
> redacted headers for a successful comparable email
This would include:
- `Message-ID`
- `From`
- `To`
- `Delivered-To`
- `Return-Path`
- top `Received:` lines
👉 Would that comparison be useful here?
* * *
### 2. Sidekiq job outcome (retry / dead set)
Since this is happening inside `Jobs::ProcessEmail`, I can check whether the jobs:
- retried
- eventually succeeded
- or landed in the dead set
Using:
```bash
./launcher enter app
rails c
Sidekiq::RetrySet.new.select { |j| j.klass == "Jobs::ProcessEmail" }
Sidekiq::DeadSet.new.select { |j| j.klass == "Jobs::ProcessEmail" }
```
👉 Would confirming the retry/dead-set behaviour help diagnose this?
* * *
1. Concurrency configuration
I mentioned I’m running with 1 web worker, but I realise Sidekiq concurrency is likely more relevant for a deadlock.
I can share the relevant values from app.yml, e.g.:
```plaintext
UNICORN_WORKERS:
SIDEKIQ_CONCURRENCY:
```
At the moment, I don’t have `SIDEKIQ_CONCURRENCY` explicitly set in app.yml, so I believe this is running with the default concurrency (i.e. multiple Sidekiq threads).
👉 Would that be important context for interpreting the deadlock?
* * *
1. PostgreSQL version
Since this is a `PG::TRDeadlockDetected`, I can also confirm the exact PostgreSQL version in use.
👉 Is that worth including?
* * *
1. Timing of inbound emails
I observed that the two failed emails were processed very close together in time (same minute).
I can extract more precise timing from logs if useful.
👉 Would tighter timing correlation help confirm whether this is a concurrency-triggered issue?
* * *
If helpful, I can gather and post all of the above in a follow-up - just wanted to check what would be most useful first.
Thanks again 👍
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [April 8, 2026, 8:32am UTC](https://meta.discourse.org/t/2-emails-rejected-by-2026-4-0-latest-5f0d95e1f1/400152/4 "2026-04-08T08:32:04Z")
Might be worth mentioning that the day after, 12 manually-triggered emails were received with time range of ~8 minutes
Yesterday evening, 4 of these automated emails were received, likely with a time range less than 8 minutes
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [April 15, 2026, 8:26pm UTC](https://meta.discourse.org/t/2-emails-rejected-by-2026-4-0-latest-5f0d95e1f1/400152/5 "2026-04-15T20:26:53Z")
> [@Ethsim2](#):
>
> ### Hosting context
>
> - self-hosted
> - using `mail-receiver`
> - small IONOS VPS
> - 1 web worker configured
>
> I realise the 1 web worker may just be background context rather than the cause, since this appears to be inbound email/background processing rather than web request handling.
i have since upgraded to the medium + IONOS VPS with twice as many cores and double memory.
```plaintext
## Set db_shared_buffers to a max of 25% of the tot>
## will be set automatically by bootstrap based on >
db_shared_buffers: "512MB"
## can improve sorting performance, but adds memory>
db_work_mem: "10MB"
## Which Git revision should this container use? (d>
#version: tests-passed
upload_size: 20m
```
```plaintext
#these API limits were changed based on https://met>
DISCOURSE_MAX_USER_API_REQS_PER_MINUTE: 40
DISCOURSE_MAX_USER_API_REQS_PER_DAY: 14560
DISCOURSE_MAX_ADMIN_API_REQS_PER_MINUTE: 130
# end of changes due to the meta topic quoted above>
```
```plaintext
## How many concurrent web requests are supported? >
## will be set automatically by bootstrap based on >
UNICORN_WORKERS: 4
## TODO: The domain name this Discourse instance wi>
## Required. Discourse will not work with a bare IP>
```
i haven’t noticed any issues in the week of trialling this server, so i am fairly certain there is no bug/regression here.
When the server was too small, Postgres did what it should.
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [May 15, 2026, 8:27pm UTC](https://meta.discourse.org/t/2-emails-rejected-by-2026-4-0-latest-5f0d95e1f1/400152/6 "2026-05-15T20:27:36Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.