Tant que ces plugins ajoutés ne sont pas activés par défaut, du moins pas pour les instances existantes, tout va bien. Mais en ce qui concerne les changements de dépendance des gems, et les multiples échecs de migration de base de données que nous avons rencontrés, je crains que quelque chose ne soit invisiblement cassé ou perdu. Malheureusement, la reconstruction ne produit aucun journal à cet égard, disant simplement que cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' s’est terminé avec un code d’erreur, mais sans détails, ni dans les journaux .
cela semble étrange, exécutez-vous PG dans un conteneur séparé, a-t-il pgvector installé ?
En général, lorsque les choses échouent, vous pouvez faire défiler un peu vers le haut et trouver l’erreur, en raison de la séquence, l’erreur est souvent 100 lignes plus haut.
Just the standalone Discourse Docker container. Also I was not fully correct, indeed there is some more output about it, but nothing I could make enough sense of:
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.2/lib/active_record/migration.rb:1454:in `migrate' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.2/lib/active_record/migration.rb:1261:in `up’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.2/lib/active_record/migration.rb:1236:in `migrate' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.2/lib/active_record/tasks/database_tasks.rb:270:in `migrate’
/var/www/discourse/lib/tasks/db.rake:267:in `block (2 levels) in <main>’ /var/www/discourse/lib/distributed_mutex.rb:53:in `block in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize' /var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize’
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize' /var/www/discourse/lib/tasks/db.rake:242:in `block in ’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.0/exe/rake:27:in `<top (required)>' /usr/local/bin/bundle:25:in `load’
/usr/local/bin/bundle:25:in `’
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
I, [2025-07-29T20:36:15.074727 #1] INFO – : == 20180828095129 PushFixTopicEmbedAuthorsJob: migrating ==========
== 20180828095129 PushFixTopicEmbedAuthorsJob: migrated (0.0021s) =============
I, [2025-07-29T20:36:15.075331 #1] INFO – : Terminating async processes
I, [2025-07-29T20:36:15.075355 #1] INFO – : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main pid: 45
I, [2025-07-29T20:36:15.075376 #1] INFO – : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 112
2025-07-29 20:36:15.075 UTC [45] LOG: received fast shutdown request
112:signal-handler (1753821375) Received SIGTERM scheduling shutdown…
2025-07-29 20:36:15.091 UTC [45] LOG: aborting any active transactions
2025-07-29 20:36:15.092 UTC [45] LOG: background worker “logical replication launcher” (PID 59) exited with exit code 1
2025-07-29 20:36:15.092 UTC [54] LOG: shutting down
2025-07-29 20:36:15.105 UTC [54] LOG: checkpoint starting: shutdown immediate
112:M 29 Jul 2025 20:36:15.125 # User requested shutdown…
112:M 29 Jul 2025 20:36:15.125 * Saving the final RDB snapshot before exiting.
112:M 29 Jul 2025 20:36:15.247 * DB saved on disk
112:M 29 Jul 2025 20:36:15.247 # Redis is now ready to exit, bye bye…
2025-07-29 20:36:15.273 UTC [54] LOG: checkpoint complete: wrote 10 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.066 s, sync=0.046 s, total=0.181 s; sync files=9, longest=0.026 s, average=0.006 s; distance=36 kB, estimate=36 kB
2025-07-29 20:36:15.276 UTC [45] LOG: database system is shut down
## FAILED
Pups::ExecError: cd /var/www/discourse && su discourse -c ‘bundle exec rake db:migrate’ failed with return #<Process::Status: pid 635 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn’
`exec failed with the params {“cd”=>“$home”, “tag”=>“migrate”, “hook”=>“db_migrate”, “cmd”=>[“su discourse -c ‘bundle exec rake db:migrate’”]}’
`bootstrap failed with exit code 1`
`** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.`
`./discourse-doctor may help diagnose the problem.`
Btw something is broken with code blocks and fences here. Neither adding backticks manually seems to work, nor selecting multiple lines and hitting the code button in the editor. It turns parts into code which were not selected at all.
Il a donc tenté une migration pour un plugin qui n’était pas présent auparavant et qui n’est pas activé ? Une idée de pourquoi cela a réussi après plusieurs tentatives de reconstruction ?
Je suis un peu confus quant à la raison pour laquelle cela a échoué, mais je vois le problème ici, nous appelons du code d’application à partir d’une migration, ce qui est très fragile.
Oui, comme dit, après plusieurs tentatives de reconstruction, cela a finalement fonctionné. Dans le dernier journal réussi, je ne vois plus du tout cette migration particulière. Probablement qu’elle a été marquée comme « migrée » malgré l’échec, donc elle n’est plus tentée lors de la prochaine reconstruction ?
La migration vient de définir une clé sur redis, une raison potentielle de son échec est que le code du plugin rss n’a pas été chargé à ce moment-là, nous allons suivre cela afin que d’autres personnes ne rencontrent pas ce problème.
.
.