Siempre que esos complementos añadidos no estén habilitados por defecto, al menos no para las instancias existentes, todo bien. Pero en cuanto a los cambios en las dependencias de gemas y los múltiples fallos de migración de bases de datos que enfrentamos, me preocupa un poco que algo pueda estar roto o perdido de forma invisible. Lamentablemente, la reconstrucción no genera ningún registro en este sentido, solo dice que cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' salió con un código de error, pero sin detalles, tampoco en los registros .
esto suena extraño, ¿estás ejecutando PG en un contenedor separado, tiene pgvector instalado?
Generalmente, cuando las cosas fallan, puedes desplazarte un poco hacia arriba y encontrar el error, debido a la secuencia, a menudo los errores están 100 líneas más arriba.
Solo el contenedor Docker de Discourse independiente. Además, no estaba completamente en lo correcto, de hecho hay más información al respecto, pero nada que pudiera entender completamente:
/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.`
Por cierto, algo está roto con los bloques de código y las vallas aquí. Ni añadir comillas invertidas manualmente funciona, ni seleccionar varias líneas y pulsar el botón de código en el editor. Convierte partes en código que no estaban seleccionadas en absoluto.
¿Así que intentó una migración para un plugin que no estaba presente antes y no está habilitado? ¿Alguna idea de por qué tuvo éxito después de múltiples intentos de reconstrucción?
Estoy algo confundido sobre por qué falló, pero puedo ver el problema aquí, estamos llamando al código de la aplicación desde una migración, lo cual es muy frágil.
Sí, como se dijo, después de múltiples intentos de reconstrucción, finalmente se realizó. En el último registro exitoso, ya no veo que esta migración en particular se haya realizado en absoluto. Probablemente se marcó como “migrada” a pesar del error, por lo que simplemente no se intentó en la próxima reconstrucción.
La migración acaba de establecer una clave en redis; una posible razón de su fallo es que, de alguna manera, el código del plugin rss no se cargó en ese momento; investigaremos esto para que otras personas no experimenten lo mismo.
.
.