Erreur de migration dans 'rename_discourse_rewind_disabled_to_enabled'

La reconstruction a échoué ~ Le journal est le suivant :

discourse -c 'bundle exec rake db:migrate'
rake aborted!
StandardError: Une erreur est survenue, ceci et toutes les migrations ultérieures sont annulées : (StandardError)
You must drop a column's default value before marking it as readonly
I, [2026-01-08T16:18:49.016491 #1]  INFO -- : Terminating async processes
I, [2026-01-08T16:18:49.018961 #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: 46
I, [2026-01-08T16:18:49.020147 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 113
2026-01-08 16:18:49.019 UTC [46] LOG:  received fast shutdown request
113:signal-handler (1767889129) Received SIGTERM scheduling shutdown...
2026-01-08 16:18:49.023 UTC [46] LOG:  aborting any active transactions
2026-01-08 16:18:49.034 UTC [46] LOG:  background worker "logical replication launcher" (PID 60) exited with exit code 1
2026-01-08 16:18:49.040 UTC [55] LOG:  shutting down
2026-01-08 16:18:49.042 UTC [55] LOG:  checkpoint starting: shutdown immediate
2026-01-08 16:18:49.057 UTC [55] LOG:  checkpoint complete: wrote 32 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.007 s, sync=0.004 s, total=0.017 s; sync files=16, longest=0.002 s, average=0.001 s; distance=180 kB, estimate=180 kB
2026-01-08 16:18:49.067 UTC [46] LOG:  database system is shut down
113:M 08 Jan 2026 16:18:49.108 # User requested shutdown...
113:M 08 Jan 2026 16:18:49.108 * Saving the final RDB snapshot before exiting.
113:M 08 Jan 2026 16:18:49.123 * DB saved on disk
113:M 08 Jan 2026 16:18:49.123 # 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 4483 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.

Désolé, c’est ma faute. La migration a mis la contrainte par défaut / nulle dans le mauvais ordre :man_facepalming:

4 « J'aime »

Ce n’est pas grave, j’attends ta correction. Courage, courage~~~

2 « J'aime »

J’ai le même problème après la dernière mise à jour.

La correction de @zogstrip pour cette migration est maintenant disponible dans latest, donc lancer une autre mise à niveau devrait rétablir le bon fonctionnement des choses.

2 « J'aime »

Je viens de reconstruire, mais ça ne fonctionne toujours pas

N’y a-t-il vraiment aucun test des prétendues « corrections » avant de considérer les choses comme corrigées ?

Cela semble être un schéma récurrent d’assurance qualité (AQ) insuffisante… Il y a eu au moins 3 cas dans ce seul problème, l’un après l’autre.

J’ai essayé de reconstruire tout à l’heure, mais cela a encore échoué. Quelle en est la raison ?

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.
1 « J'aime »

Honnêtement, je ne sais pas quel est le problème avec votre installation de Discourse. Je viens de reconstruire mon deuxième forum via le terminal du serveur et tout fonctionne à nouveau correctement. Maintenant, je vais reconstruire mon troisième forum, j’espère que ça ira aussi.

Si vous avez effectué des modifications sur les fichiers de Discourse, je sais que cela peut causer des problèmes à l’avenir. Ou si vous avez ajouté/installé manuellement des plugins.

Attendez, soyez patient et ceux qui en savent plus que moi vous aideront. C’est l’une des raisons pour lesquelles j’aime et suis passé à ce système, la communauté, c’est ce qui le rend encore plus génial.

Edit :
Cependant, sur mon troisième forum, la reconstruction n’a pas fonctionné.
FAILED

Pups::ExecError: cd /var/www/discourse && su discourse -c ‘bundle exec rake db:migrate’ failed with return #<Process::Status: pid 4466 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.
63e30cde8c7295d25def35eef74dea30714627609c3d38b49a8f80865e5759cf

Et maintenant, redirection vers mon deuxième forum… quoi… quoi… :rofl:

Merci pour votre réponse. Je n’ai effectué aucune modification et n’ai installé aucun plugin supplémentaire.

1 « J'aime »

Je n’ai pas non plus de plugins installés manuellement sur mon troisième forum, mais après la reconstruction ratée, et la redirection vers mon deuxième forum… J’ai également vérifié le fichier de configuration (nano containers/app.yml) et tout est correct là-dedans… que se passe-t-il ? :smiley:

1 « J'aime »

rebuild réussi

2 « J'aime »

Pas pour moi :frowning: J’ai heureusement un point de restauration du serveur datant du 01-05-2026. Pour la deuxième fois, je ne peux ni mettre à jour ni reconstruire Discourse. Je suis en train de le restaurer à nouveau, et une chose est claire :

  1. Sauvegarder tous les sujets/articles dans un fichier texte.
  2. Espérer que cela soit résolu soit avec une nouvelle installation de Discourse, soit avec un autre système (ce que je ne veux pas faire).

Il y a quelque chose quelque part qui m’échappe et je ne sais pas quoi, et ça me rend fou. Mais apparemment, l’uranium rétrograde fait son effet. Pour l’instant, je vais laisser les choses telles quelles et aller corriger quelques bugs dans HELLDIVERS 2 parce que je suis triste :rofl:

Je comprends vos frustrations et je m’en excuse. J’ai testé mes « corrections » localement sur ma base de données de développement locale, puis sur une base de données toute neuve, et elles ont toutes deux fonctionné parfaitement. Ensuite, j’ai testé sur une instance hébergée que j’utilise pour une communauté que je gère, et cela a également fonctionné sans problème. Cela a également passé tous nos CI (sur GitHub) publics ainsi que nos CI internes et nos tests de fumée.

Il se trouve qu’aucune de ces bases de données ne contenait de données affectées par cette migration :expressionless_face:

Je suis désolé que vous ayez tous eu une mauvaise expérience et je serai plus prudent la prochaine fois.

3 « J'aime »

Alors… est-ce sûr d’essayer maintenant ou cela ne fera-t-il qu’empirer les choses ? J’ai le même problème et je n’ai pas encore tenté de reconstruction après avoir vu ceci.

Après ma reconstruction, j’ai constaté que les données n’étaient pas à jour, puis j’ai effectué une opération de restauration à partir de la sauvegarde d’avant-hier via le panneau d’administration. Aucun problème n’a été détecté pour le moment.

1 « J'aime »

On dirait que cela a fonctionné correctement et que cela se charge normalement pour tous ceux qui se posent la question

@here pour ceux qui rencontrent des problèmes, je pense que @david et moi avons peut-être trouvé la cause première, mais c’est compliqué à reproduire localement.

Quelqu’un d’entre vous pourrait-il exécuter les requêtes SQL suivantes et rapporter les résultats ici ?

Requête 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;

Requête 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;

Requête 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';

Requête 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;

Merci :folded_hands:

2 « J'aime »

D’accord, pas de problème, je suis dehors en ce moment, je vérifierai quand je rentrerai.