Problèmes lors de la mise à jour de 3.0.0 à 3.0.1

[Massi]

Salut,

aujourd’hui, j’ai mis à jour notre application Discourse vers la version 3.0.1. La mise à jour a échoué lors du traitement de la migration postgres.
Spécifiquement ici :

2023-01-27 04:50:48.628 UTC [483] discourse@discourse ERROR:  duplicate key value violates unique constraint "index_tags_on_name"
2023-01-27 04:50:48.628 UTC [483] discourse@discourse DETAIL:  Key (name)=(e-mail) already exists.
2023-01-27 04:50:48.628 UTC [483] discourse@discourse STATEMENT:  UPDATE tags t
	SET public_topic_count = x.topic_count
	FROM (
	  SELECT
	    COUNT(topics.id) AS topic_count,
	    tags.id AS tag_id
	  FROM tags
	  INNER JOIN topic_tags ON tags.id = topic_tags.tag_id
	  INNER JOIN topics ON topics.id = topic_tags.topic_id AND topics.deleted_at IS NULL AND topics.archetype != 'private_message'
	  INNER JOIN categories ON categories.id = topics.category_id AND NOT categories.read_restricted
	  GROUP BY tags.id
	) x
	WHERE x.tag_id = t.id
	AND x.topic_count <> t.public_topic_count;
	
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

Il semble que certains tags aient des doublons. Je me suis connecté à postgres et j’ai corrigé les tags. La migration et la mise à jour se sont ensuite déroulées correctement.

Ma question est : ai-je bien géré la situation en manipulant la base de données ? J’ai seulement renommé les tags en double.
Je ne peux pas dire comment les tags en double ont été créés. Ils ont été insérés au cours des 2 à 3 dernières années.
Je ne suis pas sûr si cette situation pourrait se reproduire.

[B-iggy]

J’ai le même problème

[Ed_S]

Avez-vous eu exactement le même symptôme ?

ERROR:  duplicate key value violates unique constraint "index_tags_on_name"
DETAIL:  Key (name)=(e-mail) already exists.

[B-iggy]

Oui. C’est aussi à cause des tags dupliqués / index_tags_on_name.
Dans mon cas, le tag est juste nommé différemment.

J’essaie actuellement de comprendre :

• comment mettre à niveau ruby vers 3.0.0 car il se plaint que web-push est à 2.6.7, donc je ne peux même pas entrer dans rails c, pour faire des commandes fantaisistes pour corriger les tags
• comment supprimer le tag en toute sécurité de la base de données postgres mais aucune idée pour l’instant

[Ed_S]

Veuillez publier le fragment du journal qui montre l’erreur dans votre cas !

Si quelqu’un découvre un jour comment ces valeurs de clé dupliquées sont apparues, il appréciera plus de détails.

Désolé, je ne peux pas aider à la réparation de la base de données.

Pour le problème ruby, je pense que vous devez faire une mise à niveau en ligne de commande (*). Voir par exemple

Failed upgrade from 2.9.0.beta14 to 3.1.0.beta

This is happen to me to in my production. From 2.9.0.beta14 (2b9fa41a6e) to 3.1.0.beta1 Fetching gem metadata from https://rubygems.org/......... Fetching https://github.com/rails/sprockets web-push-3.0.0 requires ruby version >= 3.0, which is incompatible with the current version, 2.7.6 Docker Manager: FAILED TO UPGRADE #<RuntimeError: RuntimeError> /var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:209:in `run' /var/www/discourse/plugins/docker_manager/lib/docker_manage…

(*) Edit : mais voir ci-dessous, la mise à niveau échoue avec la base de données telle qu’elle est. Oups.

[B-iggy]

I, [2023-01-27T07:46:34.317438 #1]  INFO -- : \u003e cd /var/www/discourse \u0026\u0026 su discourse -c 'bundle exec rake db:migrate'
2023-01-27 07:46:45.663 UTC [584] discourse@discourse ERROR:  duplicate key value violates unique constraint "index_tags_on_name"
2023-01-27 07:46:45.663 UTC [584] discourse@discourse DETAIL:  Key (name)=(hws-connect) already exists.
2023-01-27 07:46:45.663 UTC [584] discourse@discourse STATEMENT:  UPDATE tags t
        SET public_topic_count = x.topic_count
        FROM (
          SELECT
            COUNT(topics.id) AS topic_count,
            tags.id AS tag_id
          FROM tags
          INNER JOIN topic_tags ON tags.id = topic_tags.tag_id
          INNER JOIN topics ON topics.id = topic_tags.topic_id AND topics.deleted_at IS NULL AND topics.archetype != 'private_message'
          INNER JOIN categories ON categories.id = topics.category_id AND NOT categories.read_restricted
          GROUP BY tags.id
        ) x
        WHERE x.tag_id = t.id
        AND x.topic_count <> t.public_topic_count;

rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint "index_tags_on_name"
DETAIL:  Key (name)=(hws-connect) already exists.

Cette erreur apparaît 3 fois, car l’étiquette semble être trouvée dans 3 sujets.

Je regrette d’avoir activé les étiquettes si j’avais su que cela se produirait et pourquoi il n’y avait pas d’avertissement à ce sujet sur le frontend.
Je veux juste les supprimer et enfin remettre mon forum en ligne

[B-iggy]

@Ed_S

Je pense que vous devez effectuer une mise à niveau en ligne de commande

Je peux reconstruire l’application autant de fois que je veux. Je reçois l’erreur et elle s’interrompt. Ainsi, ruby reste non mis à niveau.
Je suis bloqué.

[Massi]

Salut,

peut-être faire une sélection avec quelque chose comme :
SELECT * FROM tags WHERE name LIKE '%hws-connect%'

Vous devriez trouver plusieurs balises avec le même nom. C’était le problème dans mon cas.

[B-iggy]

J’ai fait une sélection :

Ma question est si je peux renommer la balise « hws-connect » dans la base de données sans corrompre l’infrastructure de discourse ?
Et… comment puis-je la renommer via postgres ?

[merefield (Robert)]

OK, quelques points :

@B-iggy

Je regrette d’avoir activé les tags si j’avais su que cela se produirait et pourquoi il n’y avait pas déjà un avertissement à ce sujet sur le frontend.

• vous allez devoir accepter un étrange bug lorsque vous exécutez votre propre installation d’un logiciel de plusieurs millions de dollars (soutenu par une communauté très utile) que vous avez obtenu (presque) gratuitement
• J’ai récemment mis à jour deux sites qui utilisent beaucoup les tags et je n’ai eu aucun problème.
• Au cours de mes plus de 5 années d’exécution de plusieurs instances de Discourse, je pense avoir eu un problème comme celui-ci une seule fois ?

Quoi qu’il en soit, cela ressemble beaucoup à un problème similaire à celui-ci, peut-être pouvez-vous utiliser une stratégie similaire pour le résoudre ? :

Duplicate data explorer key blocking rebuild

Hey all, Rare I ask for help, but I’m puzzled about how to resolve this. Just rebuilt my site and getting this: discourse-data-explorer is already at latest compatible version I, [2020-08-28T17:53:57.578920 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' 2020-08-28 17:54:07.380 UTC [3060] discourse@discourse ERROR: duplicate key value violates unique constraint "data_explorer_queries_pkey" 2020-08-28 17:54:07.380 UTC [3060] discourse@discourse DETAIL:…

Il semble que vous étiez déjà sur la bonne voie, il vous suffit de la suivre…

[B-iggy]

@merefield

vous allez devoir accepter le bogue occasionnel lorsque vous exécutez votre propre installation d’un logiciel de plusieurs millions de dollars (soutenu par une communauté très utile) que vous avez obtenu gratuitement

Je sais et ce n’est rien à propos de Discourse ou de la mise à niveau elle-même. Ça arrive et c’est normal.
J’aimerais juste ne pas me retrouver dans un scénario bloqué où je dois me battre contre autant de sujets (docker, ruby, postgres, discourse). Ce n’est pas mon activité quotidienne et cela demande un investissement en temps.

Merci pour le lien !
Je mettrai à jour mon statut.

[B-iggy]

Mise à jour : le meilleur à retenir de votre sujet @merefield était

Je suppose que je devrais être courageux

Fouiller dans une base de données me fait toujours peur, mais dans ce cas, cela a fonctionné.

Pour quiconque a le même problème (tags dupliqués / index_tags_on_name) :

1. Croisez les doigts et lancez la phase 1 d’Inception :
   cd /var/discourse
sudo ./launcher enter app

Si cela échoue parce que vous obtenez quelque chose comme “aucun conteneur docker en cours d’exécution” ou similaire, tapez
sudo docker ps -a --no-trunc
Cela listera votre conteneur docker disponible et son ID. Avec cela, redémarrez le conteneur.
sudo docker restart <container ID>
Ensuite, sudo ./launcher enter app devrait fonctionner.

2. Accédez à votre base de données postgres et lancez la phase 2 d’Inception :
   su discourse
psql
   Le journal d’erreurs de reconstruction aurait dû vous donner le nom du tag fautif. Dans mon cas, c’était

ERROR:  duplicate key value violates unique constraint "index_tags_on_name"
2023-01-27 07:46:45.663 UTC [584] discourse@discourse DETAIL:  Key (name)=(hws-connect) already exists.

Alors, recherchez d’abord votre tag avec

select * from tags where name='hws-connect';

Cela vous donne la table que vous pouvez voir ci-dessus dans mes publications.

3. J’ai simplement renommé le tag hws-connect en hws-connect1 avec

UPDATE tags SET name = 'hws-connect1' WHERE name='hws-connect';

4. Quittez l’Inception avec quelques coups de pied en arrière :
   \q pour quitter postgres
   exit pour quitter le conteneur docker
5. Effectuez la reconstruction à nouveau avec sudo ./launcher rebuild app
6. Soyez heureux que cela fonctionne et vérifiez sur le front-end ce que vous avez fait :
   Accédez à votre page de tags https://your-forum/tags
   
   

Je n’ai aucune idée de la façon dont cela s’est produit et pourquoi cette mise à niveau a échoué si mal - toutes les précédentes ont fonctionné, via le web ou le terminal.
Je vais nettoyer mes tags maintenant.

Bonus :

1. Vous cliquez sur le tag renommé.
2. Supprimez-le de tous les sujets. 3 dans mon cas.
3. Revenez à la page des tags et utilisez la fonctionnalité en haut à droite :
   
   

Tout est fait.
Merci à tous pour votre aide.

[merefield (Robert)]

Bravo ! Excellent travail !

[Ed_S]

Excellente explication (et bravoure démontrée) merci !

Mes forums utilisent aussi des tags - tout comme celui-ci, plein de tags :
https://meta.discourse.org/tags

Manifestement, quelque chose de rare et de malheureux peut se produire pour créer une valeur de clé en double.

[n1bff]

Moi aussi, j’ai été mordu par ça. Merci d’avoir partagé vos solutions manuelles, je viens de les utiliser pour corriger environ 20 d’entre elles.

Mon forum utilisait beaucoup de balises dans toutes sortes de MixEdCasE et cela n’a jamais été un problème jusqu’à la mise à niveau. Il semble qu’il y ait eu un bug qui a créé des doublons, quelle que soit la casse.

  id   |          name          |         created_at         
-------+------------------------+----------------------------
   707 | ParkRide               | 2019-05-21 21:36:53.213993
 18982 | ParkRide               | 2020-06-05 18:43:09.409895

(Oui, il y a une différence d’espacement entre eux)

Je suis maintenant bloqué avec un dernier doublon qui ne peut pas être corrigé :

discourse=> select name from tags group by name having count(*) > 1; 
    name    
------------
 Bike--Ride
(1 row)

discourse=> UPDATE tags SET name = 'Bike--Ride_2' WHERE name = 'Bike--Ride';
ERROR:  duplicate key value violates unique constraint "index_tags_on_name"
DETAIL:  Key (name)=(Bike--Ride_2) already exists.
discourse=> UPDATE tags SET name = 'Bike--Ride_3' WHERE name = 'Bike--Ride';
ERROR:  duplicate key value violates unique constraint "index_tags_on_name"
DETAIL:  Key (name)=(Bike--Ride_3) already exists.
discourse=> UPDATE tags SET name = 'something is broken here' WHERE name = 'Bike--Ride';
ERROR:  duplicate key value violates unique constraint "index_tags_on_name"
DETAIL:  Key (name)=(something is broken here) already exists.

alors que la mise à niveau échoue sur

2023-02-01 18:56:58.610 UTC [475] discourse@discourse ERROR:  duplicate key value violates unique constraint "index_tags_on_name"
2023-02-01 18:56:58.610 UTC [475] discourse@discourse DETAIL:  Key (name)=(Bike--Ride) already exists.

Une idée pour contourner ce problème ?

[stoney27]

Je veux dire merci. Cela m’a aidé dans ma mise à niveau !

[jamiemcclelland (Jamie)]

J’ai eu la même erreur - peu importe le nouveau nom de balise que j’utilisais, il signalait qu’il existait déjà. J’ai contourné le problème en mettant à jour la balise en utilisant l’id au lieu de la colonne name :

UPDATE tags SET name = 'tag1' WHERE id = 1234