Severe Email Issue since last update a couple days ago - 3.4.0.beta4-dev

With a small sample of watched new topics and email replies to those topics, looks promising, the email counts are mostly correct so far. This is what I did and don’t know if that fixed the issue or not, but so far it seems better, now:

I upgraded to 3.5.0.beta1-dev, forced dns nameserver to 8.8.8.8 (from 1.1.1.1) and rebooted.

I noted this:
docker image list --all

REPOSITORY TAG IMAGE ID CREATED SIZE
local_discourse/app latest 32adad867562 6 hours ago 3.68GB
none none 5306688e5dcb 9 days ago 2.74GB

but over time that changed to, without me doing anything, to:

REPOSITORY TAG IMAGE ID CREATED SIZE
local_discourse/app latest 32adad867562 26 hours ago 3.68GB
discourse/base 2.0.20250129-0720 5306688e5dcb 10 days ago 2.74GB

so, i am not sure what that ‘none’ was all about

I will keep an eye on this and report back after more data is evaluated.

I see some redis connection errors and nginx / postgres errors I will also investigate:

nginx:

2606 upstream prematurely closed connection while reading response header from upstream

redis:

Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
heartbeat: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:398:in `rescue in establish_connection'
Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)

postgres:

current:2025-02-08 04:24:06.133 UTC [75838] discourse@discourse ERROR:  duplicate key value violates unique constraint "index_post_reply_keys_on_user_id_and_post_id"
current:2025-02-08 04:24:20.624 UTC [75838] discourse@discourse ERROR:  duplicate key value violates unique constraint "index_post_reply_keys_on_user_id_and_post_id"
current:2025-02-08 08:05:19.485 UTC [91041] discourse@discourse LOG:  duration: 2345.289 ms  statement: COPY public.scheduler_stats (id, name, hostname, pid, duration_ms, live_slots_start, live_slots_finish, started_at, success, error) TO stdout;

/log - Job exception: execution expired:
Looking at this: SMTP Net::ReadTimeout without relation to net or login problems - SMTP host is just slow - #2 by Falco

Message (3 copies reported)

Job exception: execution expired

Backtrace

/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.0/lib/net/smtp.rb:663:in `initialize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.0/lib/net/smtp.rb:663:in `open'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.0/lib/net/smtp.rb:663:in `tcp_socket'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.0/lib/net/smtp.rb:672:in `block in do_start'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:185:in `block in timeout'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:192:in `timeout'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.0/lib/net/smtp.rb:671:in `do_start'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.0/lib/net/smtp.rb:642:in `start'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/message.rb:269:in `deliver!'
/usr/local/lib/ruby/3.3.0/delegate.rb:87:in `method_missing'
/var/www/discourse/lib/email/sender.rb:296:in `send'
/var/www/discourse/app/jobs/regular/user_email.rb:79:in `send_user_email'
/var/www/discourse/app/jobs/regular/user_email.rb:39:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread' 

Confirmed: Severe Email Issue seems fixed since I upgraded to 3.5.0.beta1-dev, forced dns nameserver to 8.8.8.8 (from 1.1.1.1) and rebooted.

I also extended the SMTP open_timeout to 15, but probably not needed, but I do not intend to set it back to the default of 5,

4 Likes

Happy to hear it is sorted, DNS configurations are the root of 78% of all problems in the sysadmin world.

3 Likes

I am having some new issues with email sending which have started in the last 4 days. Not sure whether best to continue this thread or start a new one, but for now will continue this one.

I had recently done a full site update from the command line around the time this issue occurred.

  • No users are being sent any notification emails about activity on the site.
  • SMTP sending seems to work fine, an email deliverability test worked instantly.
  • Sidekiq shows thousands of enqueued jobs which are retried regularly but are failing consistently. (7000+ jobs enqueued)
  • Logs show one very prominent and numerous error Job exception: UserDestroyer::PostsExistError - I have looked this up on Meta but nobody else having similar issues since at least 2017 when the last topic mentioned it. (9000+ errors all in the last 4 days)
Full stacktrace from logs
/var/www/discourse/app/services/user_destroyer.rb:18:in `destroy'
/var/www/discourse/app/jobs/onceoff/fix_primary_emails_for_staged_users.rb:23:in `block (2 levels) in execute_onceoff'
activerecord-7.2.2.1/lib/active_record/relation/delegation.rb:98:in `each'
activerecord-7.2.2.1/lib/active_record/relation/delegation.rb:98:in `each'
/var/www/discourse/app/jobs/onceoff/fix_primary_emails_for_staged_users.rb:21:in `block in execute_onceoff'
/var/www/discourse/app/jobs/onceoff/fix_primary_emails_for_staged_users.rb:14:in `each_key'
/var/www/discourse/app/jobs/onceoff/fix_primary_emails_for_staged_users.rb:14:in `execute_onceoff'
/var/www/discourse/app/jobs/onceoff/onceoff.rb:35:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'

Anyone any advice on how next to debug and proceed?

Ok just to update - the only further thing I could think of to do was git pull; ./launcher rebuild app which I just did and it does seem to have fixed the issue, emails are now being sent and the Sidekiq backlog of enqueued email jobs is starting to go down.

Reviewing the commits in discourse/discourse over the last few days I’m not sure what has fixed it. But if anyone wants to investigate further I am happy to supply further info if needed.

5 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.