Ce bug particulièrement ennuyeux est toujours là.
Pourriez-vous me donner des instructions pour régler le problème ?
Malheureusement, nous rencontrons encore ce problème de temps en temps. J’ai réussi à collecter certaines données sur un problème récent où le déplacement de 27 messages vers un sujet existant (2013 messages) a échoué :
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
La plupart des méthodes s’exécutent très rapidement, mais update_statistics a pris plus de 45 secondes dans ce cas. Tout ce temps a été consacré à l’appel de la méthode suivante :
Peut-être devrions-nous reporter le travail de mise à jour des statistiques à Sidekiq ?
Oui, probablement. Mais je vais examiner de près la complexité de déplacer l’ensemble du processus dans un job Sidekiq et de laisser l’interface utilisateur attendre qu’il soit terminé. Nous jouons un peu à « whac-a-mole » en déplaçant constamment des fragments vers des jobs.
Merci pour votre travail acharné !
Je rencontre également cette erreur 502 lorsque j’essaie de fusionner des sujets. Pas à chaque fois, mais très souvent.
Je le fais lorsqu’une personne a lancé un sujet sur un thème qui existe déjà ; je tente donc généralement de déplacer très peu de messages (pas plus de cinq).
Je n’ai pas lu l’intégralité de ce sujet, mais je comprends qu’il s’agit d’un problème connu sur lequel vous travaillez et qu’il n’y a rien que je puisse faire de mon côté ?
Je rencontre également ce problème sur notre forum. Plusieurs d’entre nous ne parviennent pas à modifier et/ou à créer de nouveaux messages. Nous obtenons le message d’erreur suivant :
Nous rencontrons également des erreurs 502 lors du déplacement de messages.
Cela se produisait auparavant occasionnellement et en insistant, cela fonctionnait. Mais maintenant, nous avons un cas où cela échoue systématiquement lors de la tentative de déplacement d’un seul message dans un sujet assez long (2 000 messages), avec un délai d’attente après environ 30 secondes.
Le serveur n’est pas particulièrement occupé lorsque cela se produit et gère très bien le reste de l’activité. Essayer de déplacer le message lorsque l’activité est faible donne le même résultat. Aucune différence avec le mode sans échec.
Outre le renforcement de l’instance (en supposant que ce soit une solution ?), y a-t-il autre chose que nous pourrions essayer ? Nous serions heureux de fournir plus d’informations si cela peut être utile. Il est utile de mentionner que je suis sur la dernière version stable — j’envisagerais de passer à la dernière version bêta s’il y a eu des changements récents à ce sujet.
Au cours du week-end (notre période la plus lente), nous avons temporairement triplé nos IOPS de stockage maximum, puis triplé le débit maximum et nous ne pouvons toujours pas déplacer un seul message vers le sujet existant avec 2k messages.
Laisser une nouvelle réponse sur le sujet lui-même ne semble pas être un problème, donc je suppose qu’il doit y avoir beaucoup plus de travail supplémentaire impliqué lorsque le message est déplacé d’ailleurs, au lieu d’être créé à nouveau. Si cela ne peut pas être fait en moins de 30 secondes, peut-être que cela devrait être fait par un travail d’arrière-plan au lieu d’échouer avec un message d’erreur ‘502’ ?
Oui, ça m’arrive aussi pour les sujets anciens et longs de plus de 3000 messages.
C’est toujours douloureux.
Bonjour,
Je rencontre un problème similaire où je ne parviens pas à fusionner un sujet avec toutes ses réponses dans un autre sujet. Le sujet vers lequel je fusionne contient 23 messages et le sujet que je déplace n’en contient que 4.
|
Journal d'erreurs
Message (4 copies signalées)
Échec du traitement correct de la réponse détournée : PG::UniqueViolation : ERREUR : la valeur de clé en double viole la contrainte unique « post_timings_unique »
DÉTAIL : La clé (topic_id, post_number, user_id)=(62975, 19, 538) existe déjà.
Trace
/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'
note : J’ai remarqué que l’erreur indique « existe déjà » mais il s’agit en fait de sujets distincts. Je ne sais pas si c’est lié, mais avant que cette erreur n’apparaisse, j’ai déplacé plusieurs sujets et leurs messages dans le sujet contenant les 23 messages dans lequel j’essaie de fusionner celui-ci (comme je l’ai fait pour les autres sujets).
Merci !
Avez-vous mis à jour ces derniers jours ? Il y a eu une correction récente concernant le déplacement de publications