Déplacer les messages vers un long sujet échoue

Bug
1

Je suis conscient que j’ai probablement dépassé le nombre raisonnable de messages à déplacer, et maintenant cela échoue avec le message :

Une erreur s'est produite lors du déplacement des messages.

J’essayais de déplacer 19 messages d’un sujet de 1 500 messages vers un sujet de 4 500 messages.

Néanmoins, ce serait formidable s’il existait une solution.

Le déplacement vers un nouveau sujet fonctionne bien.

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'

Je suis sur la dernière version principale b6f62bcc05

Y a-t-il toujours un plan pour déplacer la logique vers un Sidekiq ?

3 « J'aime »
2

Il y a un article récent sur un problème similaire :

Essayez peut-être de mettre à jour si vous n’êtes pas sur la dernière version.

2 « J'aime »
3

J’ai remarqué..

2 « J'aime »
4

Nous pourrions vous accorder un peu plus de temps et reporter cela facilement dans la file d’attente de report, ce qui vous donnerait 90 secondes contre 30 secondes pour le travail.

Je suis un peu préoccupé par le fait que cela prenne autant de temps ici, la mise à jour des statistiques semble être quelque chose que nous devrions pouvoir faire plus tard, une fois les publications déplacées.

3 « J'aime »
12

J’ai fait le détournement pour l’instant, mais oui, il y a probablement un tas d’autres optimisations à faire ici :

3 « J'aime »