A reconstrução falhou~\nO log é o seguinte:\n\n\ndiscourse -c 'bundle exec rake db:migrate'\nrake abortado!\nStandardError: Ocorreu um erro, esta e todas as migrações posteriores foram canceladas: (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 processos assíncronos\nI, [2026-01-08T16:18:49.018961 #1] INFO -- : Enviando INT para 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 para 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: recebido pedido de encerramento rápido\n113:signal-handler (1767889129) Recebido SIGTERM agendando encerramento...\n2026-01-08 16:18:49.023 UTC [46] LOG: abortando quaisquer transações ativas\n2026-01-08 16:18:49.034 UTC [46] LOG: trabalhador em segundo plano \"logical replication launcher\" (PID 60) saiu com código de saída 1\n2026-01-08 16:18:49.040 UTC [55] LOG: encerrando\n2026-01-08 16:18:49.042 UTC [55] LOG: checkpoint iniciando: encerramento imediato\n2026-01-08 16:18:49.057 UTC [55] LOG: checkpoint completo: escreveu 32 buffers (0.1%); 0 arquivos WAL adicionados, 0 removidos, 0 reciclados; write=0.007 s, sync=0.004 s, total=0.017 s; sync files=16, longest=0.002 s, average=0.001 s; distância=180 kB, estimativa=180 kB\n2026-01-08 16:18:49.067 UTC [46] LOG: sistema de banco de dados encerrado\n113:M 08 Jan 2026 16:18:49.108 # Usuário solicitou encerramento...\n113:M 08 Jan 2026 16:18:49.108 * Salvando o snapshot RDB final antes de sair.\n113:M 08 Jan 2026 16:18:49.123 * DB salvo em disco\n113:M 08 Jan 2026 16:18:49.123 # Redis está agora pronto para sair, tchau tchau...\n\n\nFALHOU\n--------------------\nPups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' falhou com retorno #\u003cProcess::Status: pid 4483 exit 1\u003e\nLocal da falha: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn'\nexec falhou com os parâmetros {\"cd\"=\u003e\"$home\", \"tag\"=\u003e\"migrate\", \"hook\"=\u003e\"db_migrate\", \"cmd\"=\u003e[\"su discourse -c 'bundle exec rake db:migrate'\"]}\nbootstrap falhou com código de saída 1\n** FALHA AO INICIALIZAR ** por favor, role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.\n./discourse-doctor pode ajudar a diagnosticar o problema.\n"
Desculpe, a culpa foi minha. A migração colocou a restrição padrão / nula na ordem errada 
Tudo bem, estarei esperando sua correção. Força, força~~~
Estou com o mesmo problema após a última atualização.
A correção do @zogstrip para essa migração já está disponível no latest, então executar outra atualização deve fazer as coisas funcionarem novamente.
Será que realmente não há testes das supostas “correções” antes de considerar as coisas resolvidas?
Parece um padrão recorrente de QA insuficiente… Houve pelo menos 3 instâncias neste 1 problema, uma após a outra.
Acabei de tentar o rebuild novamente, mas ainda falhou. Qual é o motivo?
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, não sei qual é o problema com sua instalação do Discourse. Acabei de reconstruir meu segundo fórum pelo terminal do servidor e tudo está funcionando bem novamente. Agora vou reconstruir meu terceiro fórum, espero que também funcione bem.
Se você fez alguma alteração nos arquivos do Discourse, sei que isso pode causar problemas no futuro. Ou se você adicionou/instalou algum plugin manualmente.
Espere, seja paciente e aqueles que sabem mais do que eu ajudarão. Esta é uma das razões pelas quais gosto e migrei para este sistema, a comunidade, é isso que o torna ainda melhor.
Edição:
No entanto, no meu terceiro fórum, a reconstrução não funcionou.
FALHOUPups::ExecError: cd /var/www/discourse && su discourse -c ‘bundle exec rake db:migrate’ falhou com retorno #<Process::Status: pid 4466 exit 1>
Local da falha: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn’
exec falhou com os parâmetros {“cd”=>“$home”, “tag”=>“migrate”, “hook”=>“db_migrate”, “cmd”=>[“su discourse -c ‘bundle exec rake db:migrate’”]}
bootstrap falhou com código de saída 1
FALHA AO INICIALIZAR por favor, role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.
./discourse-doctor pode ajudar a diagnosticar o problema.
63e30cde8c7295d25def35eef74dea30714627609c3d38b49a8f80865e5759cf
E agora redireciona para o meu segundo fórum… o que… o que… 
Obrigado pela sua resposta. Eu não fiz nenhuma modificação nem instalei nenhum plugin adicional.
Eu também não tenho nenhum plugin instalado manualmente no meu terceiro fórum, mas após a reconstrução falhada e o redirecionamento para o meu segundo fórum… Eu também verifiquei o arquivo de configuração (nano containers/app.yml) e está tudo certo lá… o que está acontecendo? 
Para mim não 
Felizmente, tenho um ponto de restauração do servidor de 01/05/2026. Pela segunda vez, não consigo atualizar nem reconstruir o Discourse. Agora estou restaurando novamente, e uma coisa está clara:
- Fazer backup de todos os tópicos/artigos em um arquivo de texto.
- Espero que isso seja resolvido com uma nova instalação do Discourse, ou com outro sistema (o que eu não quero fazer).
Há algo em algum lugar que estou perdendo e não sei o que é, e isso está me deixando louco. Mas aparentemente o urânio retrógrado está falando mais alto. Por enquanto, vou deixar as coisas como estão e ir corrigir alguns bugs no HELLDIVERS 2 porque estou triste
Compreendo suas frustrações e peço desculpas. Testei minhas “correções” localmente tanto no meu banco de dados de desenvolvimento local quanto em um banco de dados totalmente novo, e ambos funcionaram perfeitamente. Em seguida, testei em uma instância hospedada que administro para uma comunidade que gerencio, e funcionou bem lá também. Também passou em todos os nossos CIs (no GitHub) públicos, bem como em nossos CIs internos e testes de fumaça.
Acontece que nenhum desses bancos de dados tinha dados que foram afetados por essa migração 
…
Sinto muito que todos vocês tiveram uma experiência ruim e serei mais cuidadoso da próxima vez.
Então… é seguro tentar agora ou isso só vai piorar as coisas? Eu tenho o mesmo problema e ainda não tentei uma reconstrução depois de ver isso.
Após minha reconstrução, descobri que os dados não estavam atualizados e, em seguida, realizei uma operação de restauração usando o backup de anteontem pelo painel de administração. Atualmente, nenhum problema foi detectado.
Parece que funcionou bem e está carregando normalmente para quem mais estiver se perguntando
@here para aqueles que estão com problemas, eu acho que @david e eu podemos ter encontrado a causa raiz, mas é complicado de reproduzir localmente.
Algum de vocês poderia executar as seguintes consultas SQL e relatar os resultados aqui?
Consulta #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 #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 #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 #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;
Obrigado 