Verschieben von Beiträgen in ein langes Thema schlägt fehl

Fehler
1

Ich bin mir bewusst, dass ich wahrscheinlich die angemessene Anzahl von Beiträgen zum Verschieben überschritten habe, und jetzt schlägt es mit der Meldung fehl:

Beim Verschieben von Beiträgen ist ein Fehler aufgetreten.

Ich habe versucht, 19 Beiträge aus einem Thema mit 1.500 Beiträgen in ein Thema mit 4.500 Beiträgen zu verschieben.

Dennoch wäre es großartig, wenn es eine Lösung gäbe.

Das Verschieben in ein neues Thema funktioniert einwandfrei.

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'

Ich bin auf der neuesten Core-Version b6f62bcc05

Gibt es noch einen Plan, die Logik auf Sidekiq zu verschieben?

3 „Gefällt mir“
2

Es gibt einen aktuellen Beitrag zu einem ähnlichen Problem:

Versuchen Sie vielleicht ein Update, falls Sie nicht die neueste Version verwenden.

2 „Gefällt mir“
3

Mir ist aufgefallen..

2 „Gefällt mir“
4

Wir könnten Ihnen etwas mehr Zeit verschaffen und dies ganz einfach an die Aufschubwarteschlange weiterleiten, was Ihnen 90 Sekunden statt 30 Sekunden für die Arbeit geben würde.

Ich bin etwas besorgt, dass dies hier so lange dauert. Das Aktualisieren von Statistiken fühlt sich wie etwas an, das wir später erledigen könnten, nachdem die Beiträge verschoben wurden.

3 „Gefällt mir“
12

Ich habe den Hijack jetzt erledigt, aber ja, hier gibt es wahrscheinlich noch eine Menge anderer Optimierungen vorzunehmen:

3 „Gefällt mir“