Moving posts to a long topic fails

Bug
1

I’m aware I’ve probably exceeded the reasonable number of posts to move, and now it fails with the message:

There was an error moving posts.

I was trying to move 19 posts from a 1,500-post topic into a 4,500-post topic.

Still, it would be great if there was a solution.

Moving to a new topic works fine.

Unicorn worker received USR2 signal indicating it is about to timeout, dumping backtrace for main thread
config/unicorn.conf.rb:203:in `backtrace'
config/unicorn.conf.rb:203:in `block (2 levels) in reload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/patches/db/pg.rb:110:in `exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/patches/db/pg.rb:110:in `async_exec'
(eval at /var/www/discourse/lib/method_profiler.rb:38):29:in `async_exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/postgres/connection.rb:217:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:38:in `block in run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:34:in `block in with_lock'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:34:in `with_lock'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:38:in `run'
/var/www/discourse/lib/mini_sql_multisite_connection.rb:109:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/postgres/connection.rb:196:in `exec'
(eval at /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/builder.rb:62):2:in `exec'
/var/www/discourse/app/models/topic_user.rb:511:in `update_post_action_cache'
/var/www/discourse/app/models/post_mover.rb:634:in `update_statistics'
/var/www/discourse/app/models/post_mover.rb:116:in `move_posts_to'
/var/www/discourse/app/models/post_mover.rb:35:in `block in to_topic'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/transaction.rb:6...


activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in `block in warn' 
activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `block in dispatch' 
activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `each' 
activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `dispatch' 
activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130: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'

I’m on latest core version b6f62bcc05

Is there still a plan to move the logic to a sidekiq?

3 Likes
2

There is a recent post about a similar issue:

Maybe try to update if you’re not on the last version.

2 Likes
3

I’ve noticed…

2 Likes
4

We could buy you a bit more time and kick this to the defer queue quite easily, that would give 90 seconds vs 30 seconds for the work.

I am a bit concerned that it takes so long here, updating stats does feel like something we should be able to do later after the posts moved.

3 Likes
12

I’ve done the hijack for now, but yes there is likely a bunch of other optimizations to make here:

2 Likes