この最も面倒なバグがまだ残っています。
問題の原因を特定するための手順を教えていただけますか？
残念ながら、この問題は時々発生し続けています。最近、27 件の投稿を既存のトピック（2013 件の投稿あり）へ移動させる処理が失敗した際の問題について、いくつかのデータを収集できました：
Beginning move at 2021-05-25 20:54:57 +0000
create_temp_table
0.000134 0.000027 0.000161 ( 0.002810)
delete_invalid_post_timings
0.000317 0.000065 0.000382 ( 0.306869)
move_incoming_emails
0.000056 0.000006 0.000062 ( 0.000478)
move_notifications
0.000074 0.000008 0.000082 ( 0.005584)
update_reply_counts
0.000088 0.000010 0.000098 ( 0.001058)
update_quotes
0.000079 0.000008 0.000087 ( 0.002426)
move_first_post_replies
0.000071 0.000008 0.000079 ( 0.000695)
delete_post_replies
0.000062 0.000006 0.000068 ( 0.000834)
copy_first_post_timings
0.000064 0.000007 0.000071 ( 0.002660)
move_post_timings
0.000082 0.000009 0.000091 ( 0.008195)
copy_topic_users
0.000398 0.000043 0.000441 ( 0.043640)
move_each_post
4.345220 0.132652 4.477872 ( 3.447047)
create_moderator_post_in_original_topic
0.163962 0.000253 0.164215 ( 0.207101)
update_statistics
0.217266 0.051660 0.268926 ( 45.258070)
update_user_actions
0.000934 0.000101 0.001035 ( 0.178894)
update_last_post_stats
0.001589 0.000171 0.001760 ( 0.003156)
update_upload_security_status
0.000030 0.000003 0.000033 ( 0.000034)
update_bookmarks
0.000492 0.000054 0.000546 ( 0.003832)
Finished move at 2021-05-25 20:55:47 +0000
ほとんどの処理は非常に短時間で完了しますが、このケースでは update_statistics が 45 秒以上を要しました。その時間はすべて、以下のメソッド呼び出しに費やされています：
統計更新の処理を Sidekiq に遅延させるのはどうでしょうか？
はい、おそらくそうです。ただし、プロセス全体を Sidekiq ジョブに移行して UI が完了するまで待機させるのがどれほど複雑になるか、しっかり検討します。今までは断片的にジョブへ移行させることを繰り返しており、まるで「わっかーも」を叩いているような状態です。
お疲れ様でした！
トピックをマージしようとした際、私も同様に 502 エラーが発生します。毎回ではありませんが、頻繁に起こります。
これは、すでに存在するトピックと同じ内容で新しいトピックが作成された場合に行う処理で、通常はごく少数（5 つ以下）の投稿を移動させようとしています。
このトピック全体は読んでいませんが、これは既知の課題であり、開発チームが対応中であり、私自身でできることはないと理解しています。
投稿の移動時にも502エラーが発生しています。
以前は時折発生する程度で、再試行すれば成功することがほとんどでした。しかし、現在では、投稿数が多い（2000件程度）トピックに単一の投稿を移動しようとすると、約30秒後にタイムアウトして一貫して失敗するケースが発生しています。
この問題が発生する際、サーバーは特にビジーではなく、他のアクティビティは問題なく処理できています。アクティビティが低い時間帯に投稿を移動しようとしても、結果は同じです。セーフモードでも違いはありません。
インスタンスの強化（それが解決策の一つだと仮定して）以外に、他に試せることはありますか？もし役に立つようであれば、さらに情報を提供できます。最新の安定版を使用していることは言及する価値があります。もしこの問題に関する最近の変更があれば、最新のベータ版に切り替えることも検討します。
週末（最も利用者の少ない期間）に、ストレージの最大IOPSを一時的に3倍にし、最大スループットも3倍にしましたが、それでも2000件の投稿がある既存のトピックに1件の投稿も移動できませんでした。
トピック自体に新しい返信を残すことは問題ないようなので、投稿が新しく作成されるのではなく、どこかから移動される場合に、より多くの追加作業が必要になるのだと思います。30秒以内に完了できない場合は、'502エラー’メッセージで失敗するのではなく、バックグラウンドジョブで実行すべきでしょうか？
はい、私も3000件以上の投稿がある古い長文トピックで同様の現象が発生します。
それでも大変です。
こんにちは
同様の問題が発生しており、トピックとそのすべての返信を別のトピック投稿にマージできません。マージ先のトピックは23件の投稿があり、移動元のトピックは4件の投稿しかありません。
|
エラーログ
Message (4 copies reported)
Failed to process hijacked response correctly : PG::UniqueViolation : ERROR: duplicate key value violates unique constraint "post_timings_unique"
DETAIL: Key (topic_id, post_number, user_id)=(62975, 19, 538) already exists.
Backtrace
/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'
/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'
/var/www/discourse/app/models/post_mover.rb:517:in `move_post_timings'
/var/www/discourse/app/models/post_mover.rb:142:in `handle_moved_references'
/var/www/discourse/app/models/post_mover.rb:112: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:616:in `block in within_new_transaction'
/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/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/transaction.rb:613:in `within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/database_statements.rb:361:in `transaction'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/transactions.rb:234:in `block in transaction'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:415:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_handling.rb:296:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/transactions.rb:233:in `transaction'
/var/www/discourse/app/models/post_mover.rb:35:in `to_topic'
/var/www/discourse/app/models/topic.rb:1308:in `move_posts'
/var/www/discourse/app/controllers/topics_controller.rb:883:in `block in merge_topic'
/var/www/discourse/lib/hijack.rb:64:in `instance_eval'
/var/www/discourse/lib/hijack.rb:64:in `block in hijack'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:911:in `callback_on_resolution'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:797:in `call_callback'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:803:in `call_callbacks'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:692:in `resolve_with'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:1325:in `resolve'
/var/www/discourse/lib/scheduler/defer.rb:125:in `block in do_work'
/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/lib/scheduler/defer.rb:119:in `do_work'
/var/www/discourse/lib/scheduler/defer.rb:105:in `block (2 levels) in start_thread'
注: エラーメッセージに「already exists」と表示されていますが、実際には別々のトピックです。関連があるかわかりませんが、このエラーが表示される前に、他のトピックと同様に、複数のトピックとその投稿を、現在マージしようとしている23件の投稿があるトピックに移動しました。
よろしくお願いします！
ここ数日で更新しましたか？投稿の移動に関連する最近の修正がありました