La reconstrucción falló~\nEl registro es el siguiente:\n\n\ndiscourse -c 'bundle exec rake db:migrate'\nrake abortado!\nStandardError: Se ha producido un error y todas las migraciones posteriores se cancelan: (StandardError)\n\nYou must drop a column's default value before marking it as readonly\n\n\n\nI, [2026-01-08T16:18:49.016491 #1] INFO -- : Terminando procesos asíncronos\nI, [2026-01-08T16:18:49.018961 #1] INFO -- : Enviando INT a 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: 46\nI, [2026-01-08T16:18:49.020147 #1] INFO -- : Enviando TERM a exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 113\n2026-01-08 16:18:49.019 UTC [46] LOG: recibida solicitud de apagado rápido\n113:signal-handler (1767889129) Recibida señal SIGTERM, programando apagado...\n2026-01-08 16:18:49.023 UTC [46] LOG: abortando cualquier transacción activa\n2026-01-08 16:18:49.034 UTC [46] LOG: el proceso en segundo plano \"logical replication launcher\" (PID 60) salió con código de salida 1\n2026-01-08 16:18:49.040 UTC [55] LOG: apagando\n2026-01-08 16:18:49.042 UTC [55] LOG: inicio de checkpoint: apagado inmediato\n2026-01-08 16:18:49.057 UTC [55] LOG: checkpoint completado: se escribieron 32 buffers (0.1%); 0 archivos WAL añadidos, 0 eliminados, 0 reciclados; write=0.007 s, sync=0.004 s, total=0.017 s; sync files=16, el más largo=0.002 s, promedio=0.001 s; distancia=180 kB, estimación=180 kB\n2026-01-08 16:18:49.067 UTC [46] LOG: el sistema de bases de datos está apagado\n113:M 08 Ene 2026 16:18:49.108 # El usuario solicitó el apagado...\n113:M 08 Ene 2026 16:18:49.108 * Guardando el snapshot RDB final antes de salir.\n113:M 08 Ene 2026 16:18:49.123 * DB guardada en disco\n113:M 08 Ene 2026 16:18:49.123 # Redis está ahora listo para salir, ¡adiós!\n\n\nFALLÓ\n--------------------\nPups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' falló con retorno #\u003cProcess::Status: pid 4483 exit 1\u003e\nUbicación del fallo: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn'\nexec falló con los parámetros {\"cd\"=\u003e\"$home\", \"tag\"=\u003e\"migrate\", \"hook\"=\u003e\"db_migrate\", \"cmd\"=\u003e[\"su discourse -c 'bundle exec rake db:migrate'\"]}\nbootstrap falló con código de salida 1\n** FALLO EN EL ARRANQUE ** por favor, desplácese hacia arriba y busque mensajes de error anteriores, puede haber más de uno.\n./discourse-doctor puede ayudar a diagnosticar el problema.\n
Lo siento, fue mi culpa. La migración puso la restricción predeterminada / nula en el orden incorrecto 
No pasa nada, te esperamos a que lo arregles. ¡Ánimo, ánimo!~~~~
Tengo el mismo problema después de la última actualización.
La corrección de @zogstrip para esa migración ya está disponible en latest, por lo que ejecutar otra actualización debería hacer que las cosas vuelvan a funcionar.
¿Realmente no hay pruebas de las supuestas “correcciones” antes de considerar que las cosas están arregladas?
Parece un patrón recurrente de control de calidad (QA) insuficiente… Hubo al menos 3 instancias en este único problema, una tras otra.
我刚才试了一下 rebuild 还是失败 是什么原因？
I, [2026-01-09T05:09:31.402079 #1] INFO -- : > exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf
I, [2026-01-09T05:09:31.409979 #1] INFO -- : > sleep 10
4481:C 09 Jan 2026 05:09:31.416 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
4481:C 09 Jan 2026 05:09:31.416 # Redis version=7.0.15, bits=64, commit=00000000, modified=0, pid=4481, just started
4481:C 09 Jan 2026 05:09:31.416 # Configuration loaded
4481:M 09 Jan 2026 05:09:31.417 * monotonic clock: POSIX clock_gettime
4481:M 09 Jan 2026 05:09:31.418 # Warning: Could not create server TCP listening socket *:6379: bind: Address already in use
4481:M 09 Jan 2026 05:09:31.418 # Failed listening on port 6379 (TCP), aborting.
I, [2026-01-09T05:09:41.418357 #1] INFO -- :
I, [2026-01-09T05:09:41.421210 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled: (StandardError)
You must drop a column's default value before marking it as readonly
/var/www/discourse/lib/migration/column_dropper.rb:15:in `mark_readonly'
/var/www/discourse/plugins/discourse-rewind/db/migrate/20260105171115_rename_discourse_rewind_disabled_to_enabled.rb:15:in `up'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/migration.rb:993:in `public_send'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/migration.rb:993:in `exec_migration'
/var/www/discourse/lib/freedom_patches/schema_migration_details.rb:8:in `block in exec_migration'
I, [2026-01-09T05:09:52.683547 #1] INFO -- : Terminating async processes
I, [2026-01-09T05:09:52.684945 #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
112I, [2026-01-09T05:09:52.685640 #1] INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 112
:signal-handler (1767935392) Received SIGTERM scheduling shutdown...
2026-01-09 05:09:52.686 UTC [45] LOG: received fast shutdown request
2026-01-09 05:09:52.691 UTC [45] LOG: aborting any active transactions
2026-01-09 05:09:52.708 UTC [45] LOG: background worker "logical replication launcher" (PID 59) exited with exit code 1
2026-01-09 05:09:52.713 UTC [54] LOG: shutting down
2026-01-09 05:09:52.716 UTC [54] LOG: checkpoint starting: shutdown immediate
112:M 09 Jan 2026 05:09:52.718 # User requested shutdown...
112:M 09 Jan 2026 05:09:52.718 * Saving the final RDB snapshot before exiting.
2026-01-09 05:09:52.734 UTC [54] LOG: checkpoint complete: wrote 17 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.007 s, sync=0.004 s, total=0.020 s; sync files=14, longest=0.002 s, average=0.001 s; distance=71 kB, estimate=71 kB
2026-01-09 05:09:52.750 UTC [45] LOG: database system is shut down
112:M 09 Jan 2026 05:09:52.763 * DB saved on disk
112:M 09 Jan 2026 05:09:52.763 # Redis is now ready to exit, bye bye...
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 4484 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.
Honestamente, no sé cuál es el problema con tu instalación de Discourse. Acabo de reconstruir mi segundo foro a través de la terminal del servidor y todo está bien de nuevo. Ahora voy a reconstruir mi tercer foro, espero que también esté bien.
Si has realizado algún cambio en los archivos de Discourse, sé que puede causar problemas en el futuro. O si has añadido/instalado manualmente algún plugin.
Espera, ten paciencia y aquellos que saben más que yo te ayudarán. Esta es una de las razones por las que me gusta y cambié a este sistema, la comunidad, esto es lo que lo hace aún mejor.
Edición:
Sin embargo, en mi tercer foro, la reconstrucción no funcionó.
FALLIDOPups::ExecError: cd /var/www/discourse && su discourse -c ‘bundle exec rake db:migrate’ falló con retorno #<Process::Status: pid 4466 exit 1>
Ubicación del fallo: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn’
exec falló con los parámetros {“cd”=>“$home”, “tag”=>“migrate”, “hook”=>“db_migrate”, “cmd”=>[“su discourse -c ‘bundle exec rake db:migrate’”]}
bootstrap falló con código de salida 1
FALLO AL INICIAR por favor desplázate hacia arriba y busca mensajes de error anteriores, puede haber más de uno.
./discourse-doctor puede ayudar a diagnosticar el problema.
63e30cde8c7295d25def35eef74dea30714627609c3d38b49a8f80865e5759cf
Y ahora redirige a mi segundo foro… ¿qué… qué… 
Gracias por su respuesta. No he realizado ninguna modificación ni he instalado ningún complemento adicional.
Tampoco tengo ningún complemento instalado manualmente en mi tercer foro, pero después de la reconstrucción fallida y la redirección a mi segundo foro… También revisé el archivo de configuración (nano containers/app.yml) y todo está bien allí… ¿qué está pasando? 
Para mí no 
Por suerte tengo un punto de restauración del servidor del 01-05-2026. Por segunda vez no puedo ni actualizar ni reconstruir Discourse. Ahora lo estoy restaurando de nuevo, y una cosa está clara:
- Hacer una copia de seguridad de todos los temas/artículos en un archivo de texto.
- Con suerte, esto se resolverá con una nueva instalación de Discourse, o con otro sistema (lo cual no quiero hacer).
Hay algo por ahí que me estoy perdiendo y no sé qué es, y me está volviendo loco. Pero aparentemente el uranio retrógrado está haciendo de las suyas. Por ahora dejaré las cosas así, e iré a limpiar algunos errores en HELLDIVERS 2 porque estoy triste
Entiendo sus frustraciones y les pido disculpas. Probé mis “soluciones” localmente tanto en mi base de datos de desarrollo local como en una base de datos completamente nueva y ambas funcionaron perfectamente. Luego lo probé en una instancia alojada que administro para una comunidad y también funcionó bien allí. También pasó todas nuestras CI públicas (en GitHub) así como nuestras CI internas y pruebas de humo.
Resulta que ninguna de esas bases de datos tenía datos afectados por esa migración 
…
Lamento que todos hayan tenido una mala experiencia y seré más cuidadoso la próxima vez.
Entonces… ¿es seguro intentarlo ahora o solo lo empeorará? Tengo el mismo problema y aún no he intentado una reconstrucción después de ver esto.
Después de reconstruir, descubrí que los datos no estaban actualizados, y luego realicé una operación de restauración desde la copia de seguridad de anteayer a través del panel de administración. Hasta ahora no se ha encontrado ningún problema.
Parece que funcionó bien y está cargando normalmente para cualquiera que se pregunte.
@here para aquellos que están teniendo problemas, creo que @david y yo pudimos haber encontrado la causa raíz, pero es complicado de reproducir localmente.
¿Podrían ejecutar las siguientes consultas SQL e informar los resultados aquí?
Consulta n.º 1
SELECT table_schema, column_name, column_default
FROM information_schema.columns
WHERE table_name = 'user_options'
AND column_name = 'discourse_rewind_disabled'
ORDER BY table_schema;
Consulta n.º 2
SELECT n.nspname, n.oid
FROM pg_namespace n
JOIN pg_class c ON c.relnamespace = n.oid
WHERE c.relname = 'user_options'
ORDER BY n.oid;
Consulta n.º 3
SELECT table_schema, column_default IS NOT NULL as has_default
FROM information_schema.columns
WHERE table_name = 'user_options'
AND column_name = 'discourse_rewind_disabled';
Consulta n.º 4
SELECT nspname, oid FROM pg_namespace
WHERE nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast', 'public')
AND nspname NOT LIKE 'pg_temp%'
AND nspname NOT LIKE 'pg_toast_temp%'
ORDER BY oid;
Gracias 
De acuerdo, no hay problema. Estoy fuera ahora, esperaré a volver para consultarlo.