Probleme bei der Aktualisierung von 3.0.0 auf 3.0.1

[Massi]

Hallo,

heute habe ich unsere Discourse-App auf 3.0.1 aktualisiert. Das Update schlug fehl, als versucht wurde, die Postgres-Migration zu verarbeiten.
Speziell hier:

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:

Einige Tags schienen Duplikate zu haben. Ich habe mich mit Postgres verbunden und die Tags korrigiert. Die Migration und das Update liefen danach durch.

Meine Frage ist, ob ich es richtig gemacht habe, indem ich in der Datenbank herumgefummelt habe? Ich habe nur den Namen der doppelten Tags geändert.
Ich kann nicht sagen, wie die doppelten Tags erstellt wurden. Sie wurden in den letzten 2 bis 3 Jahren eingefügt.
Ich bin mir nicht sicher, ob diese Situation wieder auftreten könnte.

[B-iggy]

Ich habe das gleiche Problem

[Ed_S]

Haben Sie genau das gleiche Symptom bemerkt?

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

[B-iggy]

Ja. Das liegt auch an doppelten Tags / index_tags_on_name.
In meinem Fall heißt der Tag nur anders.

Versuche gerade herauszufinden:

• wie ich Ruby auf 3.0.0 upgraden kann, da es sich beschwert, dass web-push bei 2.6.7 liegt, sodass ich nicht einmal rails c eingeben kann, um schicke Befehle zum Reparieren von Tags auszuführen
• wie ich den Tag sicher aus der Postgres-Datenbank löschen kann, aber noch keine Ahnung habe

[Ed_S]

Bitte posten Sie den Log-Ausschnitt, der den Fehler in Ihrem Fall zeigt!

Wenn irgendjemand jemals herausfinden wird, wie diese doppelten Schlüsselwerte entstanden sind, wird er mehr Details zu schätzen wissen.

Entschuldigung, ich kann bei der Datenbankreparatur nicht helfen.

Für das Ruby-Problem müssen Sie meiner Meinung nach ein Kommandozeilen-Upgrade durchführen (*). Sehen Sie zum Beispiel

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…

(*) Bearbeitung: aber siehe unten, das Upgrade schlägt mit der bestehenden Datenbank fehl. Ups.

[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.

Dieser Fehler tritt 3 Mal auf, da das Tag in 3 Themen gefunden zu werden scheint.

Ich bedauere, dass ich Tags aktiviert habe, wenn ich gewusst hätte, dass dies passieren würde, und warum es im Frontend keine Warnung gab.
Ich möchte sie nur löschen und mein Forum endlich wieder zum Laufen bringen

[B-iggy]

@Ed_S

Ich glaube, Sie müssen ein Upgrade über die Befehlszeile durchführen.

Ich kann die App beliebig oft neu erstellen. Ich erhalte den Fehler und er bricht ab. Somit bleibt Ruby nicht aktualisiert.
Ich stecke im Grunde fest.

[Massi]

Hallo,

vielleicht ein SELECT mit folgendem Befehl:
SELECT * FROM tags WHERE name LIKE '%hws-connect%'

Sie sollten mehrere Tags mit demselben Namen finden. Das war in meinem Fall das Problem.

[B-iggy]

Ich habe eine Auswahl vorgenommen:

Meine Frage ist, ob ich den Tag „hws-connect“ in der Datenbank umbenennen kann, ohne die Discourse-Infrastruktur zu beschädigen?
Und… wie kann ich ihn über Postgres umbenennen?

[merefield (Robert)]

OK, ein paar Dinge:

@B-iggy

Ich bedauere, dass ich Tags aktiviert habe, wenn ich gewusst hätte, dass das passieren würde, und warum gab es keine Warnung im Frontend?

• Sie müssen gelegentliche Störungen akzeptieren, wenn Sie Ihre eigene Installation von millionenschwerer Software betreiben (unterstützt von einer super hilfreichen Community), die Sie (fast) kostenlos nutzen können.
• Ich habe kürzlich zwei Websites aktualisiert, die intensiv Tags verwenden, und hatte keine Probleme.
• In meinen > 5 Jahren, in denen ich mehrere Discourse-Instanzen betrieben habe, hatte ich ein solches Problem vielleicht einmal?

Wie auch immer, es sieht sehr ähnlich aus wie dieses Problem, vielleicht können Sie eine ähnliche Strategie zur Lösung verwenden?:

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:…

Es sieht so aus, als wären Sie hier bereits auf dem richtigen Weg, Sie müssen ihn nur weiterverfolgen …

[B-iggy]

@merefield

Sie müssen gelegentliche Störungen in Kauf nehmen, wenn Sie Ihre eigene Installation von millionenschwerer Software (unterstützt von einer super hilfsbereiten Community) betreiben, die Sie kostenlos nutzen konnten.

Ich weiß, und es hat nichts mit Discourse oder dem Upgrade selbst zu tun. Es passiert und es ist in Ordnung.
Ich wünschte nur, ich würde nicht in einem festgefahrenen Szenario landen, in dem ich gegen so viele Themen kämpfen muss (Docker, Ruby, Postgres, Discourse). Das ist nicht mein tägliches Geschäft und es ist zeitaufwendig.

Danke für den Link!
Ich werde meinen Status aktualisieren.

[B-iggy]

Update: Das Beste aus deinem Thema, @merefield, war:

Ich schätze, ich sollte mutig sein

Das Herumfummeln in einer Datenbank ist für mich immer beängstigend, aber in diesem Fall hat es funktioniert.

Für alle mit demselben Problem (duplizierte Tags / index_tags_on_name):

1. Knacke deine Finger und starte Inception Phase 1:
   cd /var/discourse
sudo ./launcher enter app

Wenn dies fehlschlägt, weil du etwas wie “no docker container running” oder so etwas erhältst, tippe
sudo docker ps -a --no-trunc
Dies listet deinen verfügbaren Docker-Container und die ID auf. Damit startest du den Container neu.
sudo docker restart <container ID>
Dann sollte sudo ./launcher enter app funktionieren.

2. Greife auf deine Postgres-DB zu und starte Inception Phase 2:
   su discourse
psql
   Das Rebuild-Fehlerprotokoll sollte dir den schuldigen Tag-Namen gegeben haben. In meinem Fall war es

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.

Suche also zuerst nach deinem Tag mit

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

Das gibt dir die Tabelle, die du oben in meinen Beiträgen sehen kannst.

3. Ich habe den Tag hws-connect einfach in hws-connect1 umbenannt mit

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

4. Verlasse Inception mit ein paar Rückwärtssprüngen:
   \q zum Verlassen von postgres
   exit zum Verlassen des Docker-Containers
5. Führe den Rebuild erneut mit sudo ./launcher rebuild app durch
6. Freue dich, dass es funktioniert, und überprüfe im Frontend, was du getan hast:
   Gehe zu deiner Tag-Seite https://your-forum/tags
   
   

Ich habe keine Ahnung, wie es passiert ist und warum dieses Upgrade so schlecht fehlgeschlagen ist - alle vorherigen funktionierten, über Web oder Terminal.
Ich werde meine Tags jetzt aufräumen.

Bonus:

1. Klicke auf den umbenannten Tag.
2. Entferne ihn aus allen Themen. In meinem Fall 3.
3. Gehe zurück zur Tag-Seite und benutze die Funktion oben rechts:
   
   

Alles erledigt.
Danke für eure Hilfe, Leute.

[merefield (Robert)]

Gut gemacht! Ausgezeichnete Arbeit!

[Ed_S]

Tolle Erklärung (und bewiesene Tapferkeit) danke!

Meine Foren verwenden auch Tags – genau wie dieses hier, jede Menge davon:
https://meta.discourse.org/tags

Offensichtlich kann etwas Seltenes und Unglückliches passieren, um einen doppelten Schlüsselwert zu erzeugen.

[n1bff]

Ich bin auch davon betroffen. Danke für das Teilen deiner manuellen Korrekturen, ich habe gerade damit ~20 davon behoben.

Mein Forum hat viele Tags in jeglicher Schreibweise verwendet und das war bis zum Upgrade nie ein Problem. Es scheint, als ob es einen Bug gab/gibt, der Duplikate unabhängig von der Groß-/Kleinschreibung erzeugte.

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

(Ja, es gibt Unterschiede im Leerraum darum)

Ich habe jetzt noch ein letztes Duplikat und es kann nicht behoben werden:

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.

während das Upgrade fehlschlägt bei

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.

Irgendeine Idee, wie man das umgehen kann?

[stoney27]

Ich möchte mich bedanken. Das hat mir bei meinem Upgrade geholfen!

[jamiemcclelland (Jamie)]

Ich hatte den gleichen Fehler – egal welchen neuen Tag-Namen ich verwendete, es wurde gemeldet, dass er bereits existiert. Ich habe es umgangen, indem ich den Tag anhand der ID anstelle der Namensspalte aktualisiert habe:

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