502 Error / Unicorn Timeout on Rewind page for highly active users

AI-generated summary

A discussion on a Discourse forum highlights a 502 error and Unicorn timeout issue on the Rewind page for highly active users. Don reports that the problem occurs due to a timeout during data aggregation, with logs showing a USR2 signal indicating the worker is exceeding its timeout limit while executing a database query. The issue consistently affects users with high activity levels, such as User 1 with 11,709 posts and 41,569 reactions given, and User 2 with 5,959 posts and 37,974 reactions given. Sam asks for more details on user activity, and Don provides the statistics. Sam acknowledges the report and states that someone will investigate in the coming weeks. Martin suggests a potential fix via a GitHub pull request.

Hello :waving_hand:

We are experiencing an issue with the Discourse Rewind plugin. For some of our most active users, the Rewind page fails to load and returns a 502 error.

  • The issue seems to be a timeout during the data aggregation process.
  • It consistently happens for users with high activity levels, while working fine for average users.
  • The logs indicate that the Unicorn worker receives a USR2 signal because it exceeds the timeout limit while executing a database query.

Error in console:

Warning in logs:

Message

Unicorn worker received USR2 signal indicating it is about to timeout, dumping backtrace for main thread
config/unicorn.conf.rb:204:in `backtrace'
config/unicorn.conf.rb:204:in `block (2 levels) in reload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-4.0.1/lib/patches/db/pg/alias_method.rb:112:in `exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-4.0.1/lib/patches/db/pg/alias_method.rb:112:in `async_exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:167:in `perform_query'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/abstract/database_statements.rb:556:in `block (2 levels) in raw_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:1017:in `block in with_raw_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:986:in `with_raw_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/abstract/database_statements.rb:555:in `block in raw_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/notifications/instrumenter.rb:58:in `instrument'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:1137:in `log'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/abstract/database_statements.rb:554:in `raw_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/abstract/database_statements.rb:591:in `...

Backtrace

/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/broadcast_logger.rb:218:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/broadcast_logger.rb:217:in `map'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/broadcast_logger.rb:217:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/broadcast_logger.rb:129:in `warn'
/var/www/discourse/lib/signal_trap_logger.rb:40:in `public_send'
/var/www/discourse/lib/signal_trap_logger.rb:40:in `block (2 levels) in ensure_logging_thread_running'
<internal:kernel>:187:in `loop'
/var/www/discourse/lib/signal_trap_logger.rb:37:in `block in ensure_logging_thread_running'

Thanks

3 Likes

Thanks @Don what scale are we talking here, can you give us a clue on how active this user is? (posts a year / likes a year)

2 Likes

Sure, here are some stats (last year) for two of the affected users:

User 1

  • Posts created: 11,709
  • Reactions given: 41,569
  • Reactions received: 74,603

User 2

  • Posts created: 5,959
  • Reactions given: 37,974
  • Reactions received: 38,875

Both users trigger the 502 error, suggesting the timeout threshold is hit even with the moderately lower (but still high) activity of User 2.

1 Like

Thanks heaps Don, someone will have a look over the next couple of weeks.

1 Like

I think this fix should help:

https://github.com/discourse/discourse/pull/36940/

4 Likes