Heute habe ich versucht, meine Discourse-Installation von 2.9.0.beta9 auf 2.9.0.beta10 zu aktualisieren. Aber das ist furchtbar schiefgegangen.
Mein erster Versuch war auf der Konsole
cd /var/discourse
sudo git pull
sudo ./launcher rebuild app
Dies brach schließlich mit der folgenden Meldung irgendwo in der Mitte aller Protokolle ab:
PG::InvalidParameterValue: ERROR: cannot extract elements from a scalar
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:110:in `exec'
Ich konnte das Forum einfach wiederherstellen, indem ich das alte Image startete (das noch vorhanden war).
Mein zweiter Versuch erfolgte über die Webkonsole (/admin/upgrade). Aber dieser scheiterte schließlich an der gleichen Art von Fehler: ERROR: cannot extract elements from a scalar. Als ich zum Upgrade-Panel zurückkehrte, wurde mir mitgeteilt, dass alle Komponenten erfolgreich aktualisiert wurden. Aber nach einem Neustart des Containers warf der Server nun einen HTTP 500-Fehler
Ich habe eine Neuinstallation auf einem separaten Rechner durchgeführt und von Grund auf neu begonnen. Ich konnte die Beta10-Version installieren, aber der Versuch, aus einem Backup wiederherzustellen, verursachte genau den gleichen Fehler!
Ich habe die Abfrage gefunden, die sie zum Stocken bringt
INSERT INTO question_answer_votes (post_id, user_id, created_at)
SELECT
X.post_id AS post_id,
(X.value->>'user_id')::int AS user_id,
(X.value->>'created_at')::timestamp AS created_at
FROM (
SELECT
post_id,
jsonb_array_elements(value::jsonb) AS value
FROM post_custom_fields WHERE name = 'vote_history'
) AS X
WHERE (X.value->>'action') != 'destroy'
ORDER BY (X.value->>'created_at')::timestamp DESC
ON CONFLICT DO NOTHING
Wenn ich das richtig verstehe, passiert das, weil die psql-Funktion jsonb_array_elements ein Array erwartet, aber einen NULL-Wert erhält.
Die Website, die ich gesehen habe, hatte eine Reihe von Post Custom Fields, die eine Reihe von Zeichenketten enthielten, die mehrmals kodiert waren, so dass sie unbrauchbar waren.
Einige Lösungen, in absteigender Reihenfolge der Komplexität:
das Plugin nicht mehr verwenden (und vielleicht zu den neuen Upvotes wechseln)
alle löschen
die schlechten löschen
diese Felder bearbeiten, um die Daten wieder in gültige JSON-Zeichenketten umzuwandeln.
Die Website, die ich gesehen habe, hatte seit Jahren alte, fehlerhafte Daten. Dies scheint ein Fehler zu sein, der vor Jahren existierte und erst jetzt entdeckt wird.
Es wäre vielleicht möglich, Code zu schreiben, um die kaputten JSON-Zeichenketten zu reparieren, aber ich konnte in 10 Minuten nicht sehen, wie das geht.
Dies fühlt sich wie eine Datenkontamination von alten Q&A-Posts an, wie Sie sagten. Ich finde es auch lustig, dass dies jetzt auftaucht, da diese Migration vom November 2021 stammt – ich nehme an, das liegt daran, dass JayJay erst jetzt auf den neuen Plugin umsteigt? Auf jeden Fall werden wir uns diese Migration noch einmal ansehen.
Wenn ich das Plugin entfernen würde, würde das Wiederherstellen des Backups immer noch die fehlerhafte Abfrage ausführen.
Daher müsste ich sowohl das Plugin als auch jede Tabelle + Abfrage entfernen, die von diesem Plugin verwendet wird.
Woher wüsste ich die beteiligten Tabellen?
Ich werde das jetzt versuchen. Ich habe die Datei dump.sql, die Teil des Backups ist, durchgesehen, und es gibt keine Erwähnung einer question_answer_* Tabelle. Das gibt mir Hoffnung…
Die korrupten Daten befinden sich in der Tabelle PostCustmField. Wenn Sie das Plugin jedoch nicht haben, wird versucht, diese Daten nicht in die neue Tabelle zu migrieren.
Das Problem ist nicht die Migration selbst, sondern dass die Daten irgendwann in der Vergangenheit beschädigt wurden. Sie sind kaputt, aber sie sind auf eine Weise kaputt gegangen, die jahrelang unbemerkt blieb. Ich denke, dass vielleicht jeder neue Upvote sie weiter beschädigt hat. Eine sinnvolle Lösung könnte darin bestehen, die beschädigten Daten zu ignorieren, sie vielleicht als beschädigt zu markieren (vielleicht das benutzerdefinierte Feld umbenennen), damit zukünftige Migrationen sie ignorieren könnten und jemand sie nach Belieben von Hand reparieren könnte.
Erfolg auch im Live-Betrieb. Das Plugin wurde deaktiviert, und wir konnten fortfahren.
Ich frage mich immer noch, warum ich dieses Problem nicht früher bemerkt habe. Wie gesagt, jeden Monat aktualisieren wir routinemäßig alle unsere Systeme, daher hätte ich dieses Problem früher sehen müssen.
Wie könnte ich selbst eine Verbindung zur Discourse-DB herstellen, um zu überprüfen, was in der Tabelle post_custom_fields steht?
Das alte QnA-Plugin verwendete standardmäßige Discourse-Typumwandlung für benutzerdefinierte Felder, die dazu dient, dieses Feld in JSON umzuwandeln. Aber das funktioniert in einigen Fällen (wie diesem) einfach nicht, weshalb man (idealerweise) Formatprüfungen einbauen muss, wenn man mit benutzerdefinierten Discourse-Feldern arbeitet (insbesondere, wenn man mit ziemlich altem Code und Daten wie diesen arbeitet). Ich würde vorschlagen, dass das Upvotes-Plugin hier das tun muss, was tatsächlich die unmittelbare Fehlerquelle ist.
Sie können das Data Explorer-Plugin verwenden, um zu überprüfen, was Sie dort haben.
Nun, ich gebe Ihnen da meistens Recht und ich denke, wir sind uns einig. Ich denke, es stimmt, dass die Migration funktioniert, wenn die Daten nicht beschädigt sind. Wir sind uns einig, dass es, wenn die Daten beschädigt sind, gnädiger fehlschlagen sollte, als es jetzt der Fall ist.
Ja, aber die Daten wurden wahrscheinlich vor Jahren beschädigt (das ist bei der Website, die ich kenne, der Fall), aber Sie haben es nicht bemerkt, weil es nicht katastrophal fehlgeschlagen ist. Ich bin mir ziemlich sicher, dass die Upvotes nicht wie erwartet verwaltet wurden, aber niemand hat es bemerkt.
Ich würde es von Rails aus tun, so etwas wie:
./launcher enter app
rails c
Dann so etwas wie:
all_votes=PostCustomField.where(name: "vote_history")
likely_broken_votes=PostCustomField.where(name: "vote_history").where("value like '\\\"%'")
Nur die ID und die Daten anzeigen:
all_votes.pluck(:id,:value)
Eine einzelne pcf abrufen:
pcf=PostCustomField.find(1234)
Korrigieren
pcf.value='the stuff you really want in it'
pcf.save
Manche Leute haben eine sehr alte Version des Frage-Antwort-Plugins mit meinem persönlichen GitHub-Benutzernamen in der Repository-URL in ihrer app.yml-Datei.
Ich habe das QnA-Plugin vor Jahren an paviliondev übertragen. GitHub leitet Repository-URLs um, wenn sie übertragen werden, sodass die alten URLs mit meinem persönlichen Benutzernamen weiterhin funktionierten.
Jahre später hat Pavilion das Frage-Antwort-Plugin an Discourse übertragen. Discourse behielt zunächst den Namen discourse-question-answer bei.
Vor ein paar Monaten habe ich meinen eigenen Fork des Plugins erstellt, das in discourse gehostet wird, während es noch discourse-question-answer hieß.
Leute mit sehr alten Links zum QnA-Plugin, die meinen persönlichen GitHub-Account enthielten, klonten nun meinen neuen Fork des erheblich aktualisierten discourse-question-answer, das in discourse gehostet wird. Mit anderen Worten, ein sehr alter Link zeigte nun auf einen Fork eines neuen Plugins. Trotz der vergangenen Jahre hätte ich das vorhersehen sollen, daher bitte ich um Entschuldigung. Ich habe diesen Fork entfernt.
Discourse hat den Namen von discourse-question-answer in discourse-upvotes geändert. Diese Namensänderung hatte keine wesentlichen Auswirkungen auf Ihren Fall @Jaap-Jan_Swijnenburg, aber sie ist der Grund, warum Sie jetzt (unerwartet) einen Fork dieses Repos klonen.
Eine Migration in discourse/discourse-upvotes (ehemals discourse-question-answer) geht davon aus, dass die Spalte value in post_custom_fields JSON-typsicher ist.
Alte Daten, die vom Plugin erstellt wurden, als es angusmcleod/discourse-question-answer war (vor Jahren), wurden vom HasCustomFields-Concern in discourse/discourse nicht als gültiges JSON gespeichert. Ich vermute, dass diese Daten wahrscheinlich bevor die JSON-Typüberprüfung vor 4 Jahren hinzugefügt wurde hinzugefügt wurden (Es ist in Ausnahmefällen immer noch möglich, ungültiges JSON in benutzerdefinierten Feldern zu haben, die als JSON registriert sind).
Daher:
Wenn Leute mit der (jahrealten) angusmcleod/discourse-question-answer-URL in ihrer app.yml ihr Discourse aktualisieren, wird die Migration in der neuen Version des Plugins geklont, die Migration läuft und erstellt möglicherweise diesen Fehler.
Es gibt ein paar Lösungen dafür:
@Jaap-Jan_Swijnenburg In Ihrem Fall müssen Sie nur den Verweis auf mein altes QnA-Plugin entfernen, und Sie können Ihre Website neu erstellen. Das ist alles; nichts weiter. Sieht so aus, als hätten Sie das bereits getan
Die Migration des Plugins discourse/discourse-upvotes könnte aktualisiert werden, um Nicht-JSON-Werte in der Spalte value in post_custom_fields zu verarbeiten.
Ich möchte darauf hinweisen, dass 2 auch den zusätzlichen Fall von Personen abdecken würde, die tatsächlich von einer alten Version des QnA-Plugins zu discourse-upvotes wechseln möchten. In diesem Fall wird die Migration ausgeführt und schlägt fehl, wenn Einträge in der Spalte value von post_custom_fields kein gültiges JSON sind.
