Etherpad-lite: Nicht erfasster Fehler: Fehlerhafte Bestätigung: Ungültiger Änderungssatz (checkRep fehlgeschlagen)

Probieren Sie den neuesten Entwicklungszweig aus und teilen Sie uns mit, ob er noch auftritt

Dies ist nicht trivial, da es zufällig auf dem Produktserver bei vielen Benutzern auftritt und ich es nicht reproduzieren kann.
Ich kann nur testen, ob kaputte Pads bei der Entwicklung kaputt bleiben, wenn das hilft.

ja bitte

Ich werde die Datenbank nächste Woche auf dev kopieren lassen. Wird so schnell wie möglich berichten. Vielen Dank für die schnelle Antwort.

Leider hat der Umzug zur Entwicklung die beschädigten Pads nicht repariert. Interessanterweise hat das Verschieben von Servern (einfacher SQL-Export / -Import) eines der Pads "repariert". Es funktioniert auf dem neuen Server (sogar auf 1.3.0), andere Schadenspads jedoch nicht. Immer noch der gleiche Fehler.

Dies ist ein wirklich seltsamer Fehler, und die Pads scheinen sich selbst auf PROD manchmal nur "selbst zu reparieren", ohne dass sich etwas an uns ändert.

Theoretisch sollte dieses Problem überhaupt nicht auftreten, da die schlechten Daten jetzt niemals ihren Weg finden sollten.

Ich kann dies offen lassen und wenn es bei frischen Daten auftritt, können wir versuchen, es zu beheben.

Was meinst du mit "frischen Daten"? Muss ich PROD auf Entwicklung setzen und versuchen, neue kaputte Pads zu bekommen?

Hrm, das wäre möglicherweise schmerzhaft. Vielleicht warten Sie auf 1.4, die in maximal ein paar Wochen herauskommen sollte.

Wir könnten das tun. Vielen Dank.

Ich habe auch dieses Problem mit der gleichen seltsamen Zufälligkeit. Ich habe auf etherpad-lite 1.4 aktualisiert und es ist immer noch da. URL für eines der Pads http://etherpad.usabilidoido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4

Ich bin gerade dabei, ein Upgrade auf 1.4 durchzuführen und hoffentlich mit der neuen Version live zu gehen, damit ich überprüfen kann, ob nach dem Ausführen der neuen Version neue Fehler in neuen Pads auftreten.

@usabilidoido Sie können Ihren Benutzern mitteilen, dass sie das Pad exportieren und importieren sollen. Sie können auf Steuerelemente zugreifen, indem Sie der folgenden URL / timeslider hinzufügen: http://etherpad.usabilidoido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4 / timeslider

Als HTML exportieren und dann in ein neues Pad importieren.

Ich habe dieses Problem in 1.4. Auf defekten Pads zeigt die Befehlszeile [WARN] client - Uncaught TypeError: Cannot read property 'length' of undefined wenn der Browser den Fehler Failed assertion anzeigt.

Hutspitze zu

Dies ist nur eine Vermutung, aber wenn Sie möchten, versuchen Sie es mit dem experimentellen Zweig try/client-init-remove-checkRep ich gerade erstellt habe. (Dies ist im Allgemeinen eine gefährliche Sache, aber es ist einen Versuch wert, denke ich.)

Ich habe alles auf 1.4 aktualisiert. und gestern hatten wir wieder ein kaputtes Pad. Könnte immer noch eine sein, die vor dem Update kaputt gegangen ist, aber ich bin mir nicht sicher. Ich werde weiter suchen.

@marcelklehr Leider kann ich den Produktionsserver nicht auf eine gefährliche Version verschieben. Und ich kann Anfragen nicht an einen sekundären Server spiegeln, weil ich nicht über die Ressourcen verfüge. : - /

Entschuldigung, mir war nicht klar: Führen Sie in der Produktion nicht try/client-init-remove-checkRep aus, sondern versuchen Sie, mit Etherpad auf diesem Zweig auf die defekten Pads zuzugreifen.

Ich habe checkRep in diesem Zweig entfernt, da ich vermute, dass die Normalisierung in einigen Fällen möglicherweise nicht richtig funktioniert. Wenn also ein defektes Pad in diesem Zweig problemlos funktioniert, müssen wir diese Methode erneut anwenden.

@marcelklehr habe ich gerade gemacht, und leider hat es nicht geholfen.

Prozess:

git fetch
git checkout try/client-init-remove-checkRep
git status
On branch try/client-init-remove-checkRep
Your branch is up-to-date with 'origin/try/client-init-remove-checkRep'.

Ich habe bestätigt, dass sich die Änderung tatsächlich im Dateisystem befindet. (Kommentar und neue Zeile sind da) Fehler ist immer noch der gleiche.

Ich habe den Fehler erhalten, den @ericpedia erwähnt hat, und er ist nicht auf anderen Pads als dem beschädigten

Konsole auf Server:

[2014-05-09 16:55:39.152] [WARN] client - Uncaught TypeError: Cannot read property 'length' of undefined -- { errorId: 'dTtndCRA5gonLZyvMlqw',
  msg: 'Uncaught TypeError: Cannot read property \'length\' of undefined',
  url: 'http://localhost:9001/p/OkTJWMYVNs',
  linenumber: 15,
  userAgent: 'Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36' }

Wenn ich den Server beende, wird die Nachricht im Client angezeigt, außerdem:

Möglicherweise kann ich Ihnen einen SQL-Import des defekten Pads geben, aber Sie müssen mir zuerst mitteilen, was genau Sie aus der Datenbank extrahieren müssen. :-)

Der eigentliche Pad-Inhalt wäre sehr hilfreich, so dass dies der DB-Schlüssel pad:<PADID> (http://etherpad.org/doc/v1.4.0/#index_pad_padid) und möglicherweise einige der letzten Revisionen wären.

Ich glaube ich komme näher:

checkPad sagt:

$ bin/checkPad <padID>
[WARN] console - DirtyDB is used. This is fine for testing but not recommended for production.
[ERROR] console - Bad changeset at revision 4901 - Failed assertion: mismatched apply: 11636 / 11635
[ERROR] console - Bad changeset at revision 11401 - Failed assertion: mismatched apply: 42094 / 42093
[ERROR] console - Bad changeset at revision 12301 - Failed assertion: mismatched apply: 48875 / 48874
[ERROR] console - Bad changeset at revision 13601 - Failed assertion: mismatched apply: 60227 / 60226
[INFO] console - finished

Nicht übereinstimmende Anwendung in allen Fällen bedeutet, dass der betreffende Änderungssatz ein Zeichen weniger als tatsächlich vorhanden erwartete (also ein unerwartetes Zeichen). Nachdem ich den Datenbankspeicherauszug untersucht hatte, stellte ich fest, dass alle diese Änderungssätze einer Revision mit einem angehängten Text folgen (nicht alle Revisionen enthalten den vollständigen Pad-Inhalt, sondern nur das Delta, aus Leistungsgründen jedoch gelegentlich den vollständigen Inhalt sind angehängt).

Vermutlich ist mit dieser Meta-Eigenschaft etwas schief gegangen, entweder beim Speichern der Revision oder beim Erstellen des aktuellen Textes für einen neuen Pad-Client.

Ich habe gerade checkPad neu geschrieben, um den berechneten Text anstelle des zwischengespeicherten zu verwenden, und das Pad wird übergeben. Sogar die zwischengespeicherten Texte sind korrekt! Dies lässt mich denken, dass es einen Fehler in einem Algorithmus gibt, der den vollständigen Text für die client_vars berechnet!

Gute Arbeit bisher Marcel. Klingt so, als ob Sie kurz davor sind, dieses Problem zu lösen.

Ah, es ist nicht der client_vars-Generator. Der Algorithmus, der für die Erstellung des zwischengespeicherten Textes verantwortlich ist, ist fehlerhaft.

@ Ra1d3n Als Quickfix können Sie Ihre defekten Pads wiederbeleben, indem Sie die Eigenschaft atext meta aus allen Schlüsselrevisionen löschen (wobei revNo % 100 == 0 ). Das "erneute Einfügen" aller Datensätze, die sich auf ein defektes Pad beziehen, wurde vor langer Zeit als Korrektur für ähnliche Probleme gemeldet - jetzt wissen wir, warum es funktioniert :)

@marcelklehr Wird EP das Pad ab Revision 0 unter Last neu

Ich habe einige Änderungen am checkPad-Skript vorgenommen. Siehe hier: # 1653
Aber das ist eher ein schmutziger Hack. Wenn mein Skript dieses Problem löst, schreibe ich ein Skript, um Pads zu reparieren

Cool, ich freue mich darauf. Im Moment bekommen wir nur ungefähr ein kaputtes Pad pro Woche, daher neige ich dazu, auf eine ordnungsgemäße Lösung zu warten. :-) Vielen Dank.

Ja, ich dachte an ein Drehbuch.

Der Unterschied zwischen dem berechneten und dem zwischengespeicherten Text zeigt also, dass "концертов" irgendwie in "ко цертов" umgewandelt wurde. In einer anderen Revision wurde "з" ebenfalls in " " umgewandelt ...

Ich bin mir nicht sicher, worum es geht. Diese Zeichen befinden sich im Unicode-BMP, afaik, daher weiß ich nicht, was mit ihnen passiert ist.

Die Mutationen in @ Ra1d3ns Pad treten in den Schlüsselrevisionen 4900, 11400, 12300 und 13600 auf (jede 100. Umdrehung ist eine Schlüsselumdrehung, was bedeutet, dass der gesamte Pad-Inhalt zwischengespeichert wird). Außerdem ist der im Pad-Datensatz gespeicherte AttributedText ebenfalls beschädigt. Alle anderen wichtigen Überarbeitungen sind in Ordnung. (analysiert mit diesem Skript )

Die Zeichen scheinen nicht zufällig zu sein. Eigentlich ragt nichts heraus. Ich sehe kein Muster.

Ich vermute, dass beim Speichern des AttributedText in der Datenbank etwas schief geht. Da sich das Pad manchmal zwischen defekten Tastenrevisionen erholt, schätze ich, dass der im Speicher gespeicherte Text gut ist. Manchmal, wenn es in der Datenbank gespeichert ist, wird es jedoch irgendwie beschädigt. Wenn Autoren das Dokument weiter bearbeiten, bis die nächste Schlüsselrevision erstellt wird und diese Revision nicht beschädigt wird, wird niemand etwas bemerken.
Wenn der Server jedoch vor dem erfolgreichen Herunterfahren des gültigen AText im Speicher in der Datenbank heruntergefahren wird, wird das Pad beim nächsten Serverstart unterbrochen.

@marcelklehr Wir hatten einen Absturz des Etherpads und erholten uns einige Male aufgrund eines Plugins, das nicht gut codiert war. Könnte dies die Ursache sein? Seltsam, dass es nur ein Buchstabe ist, der jedes Mal beschädigt wurde.

Ich habe ein Skript erstellt, um den gesamten Datenbankwert eines Pads wieder einzufügen. Auf meinen kaputten Pads hat das Skript nicht funktioniert.
@ Ra1d3n Sie können das Skript hier herunterladen: https://github.com/Gared/etherpad-lite/blob/pad-repair-script/bin/repairPad.js
Stellen Sie sicher, dass Ihre Etherpad-Instanz nicht ausgeführt wird, während Sie dieses Skript ausführen.

@Gared Woher die Werte in Ihrem Skript? Ich empfehle, meine checkPad-Gabel zu bearbeiten und zu optimieren, um die neu berechneten AttributedText-Werte in die Datenbank einzufügen.

@ Ra1d3n Etherpad-Abstürze verursachen wahrscheinlich keine Datenbeschädigung, würde ich sagen.

@marcelklehr Es hat das Problem wahrscheinlich nur sichtbarer gemacht, weil in diesen Fällen der richtige Speicherwert für uns verloren gegangen ist.

@marcelklehr Dieses Skript ist eine Abzweigung aus dem Skript extractPadData. Die Werte und Tasten werden in der obigen Funktion geladen. Dies sind alles Tasten eines Pads.

Das Skript "paraturPad.js "von @Gared repariert meine kaputten Pads. Gibt es eine Chance, dass dieses Update in die nächste Etherpad-Lite-Version aufgenommen wird?

Sicher, senden Sie einfach eine Pull-Anfrage mit oder fragen Sie @Gared an

Geöffnete Pull-Anfrage # 2210

Mein Etherpad läuft auf 1.4.1 und ich habe dreimal das gleiche Problem wie oben beschrieben: Das Pad kann nicht geladen werden, aber / timeslider funktioniert gut.
2 von ihnen werden jetzt erneut ausgeführt, ohne etwas zu tun.
Auf dem dritten Pad habe ich erfolglos versucht, dieparaturPad.js. Die URL lautet: +1: http://portail.univ-lille1.fr/etherpad/link.jsp?groupID=g.jfobkKVrkydeTwLY&padID=SES_Grp8_Macroeconomie (Sie müssen auf "utilisez le pad avec l'invitexy" klicken, um darauf zuzugreifen das Paditself.

Vielleicht gibt es einen Änderungssatz mit einem anormalen Wert, der von RepairPad nicht berücksichtigt wird, oder gibt es eine neue Version von reparPad.js, die ich auf git nicht gesehen habe?

Wir denken, wir haben jetzt eine Lösung dafür. Bitte ziehen Sie entwickeln und testen :) Danke!

Hallo, das ist gerade passiert. Wir führen 1.5.7 aus, das ist die letzte veröffentlichte Version. Backend ist eine MySQL-Datenbank. Ich habe keine Hinweise auf Benutzeraktionen, die dies verursacht haben könnten.

Pad in Frage: https://etherpad.wikimedia.org/p/iOS-iteration-planning

Das Abrufen der Pad-Daten über den Timeslider-Trick funktioniert einwandfrei. Das Pad wird jedoch niemals geladen.

Alles in der Datenbank kann gesichert und zum Debuggen bereitgestellt werden, wenn es hilft.

Hallo, ich hatte diese Diskussion am Morgen.
08:47 <webzwo0i> mutante: Ich habe das Pad getestet. Normalerweise sollten Sie dies nicht tun, aber wenn Sie eine Datenbanksicherung haben (und nachdem Sie export / etherpad erstellt haben, um eine Sicherung von zu haben
das Pad) Sie können drei Datenbankeinträge ändern und das Pad sollte wieder einwandfrei funktionieren. Die drei MySQL-Befehle sind

mysql> update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS-iteration-planning";
mysql> update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS-iteration-planning:revs:7200";
mysql> update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS-iteration-planning:revs:7300";

08:49 <webzwo0i> können Sie überprüfen, ob in Ihrer Datenbank der Zeichensatz utf8mb4 oder utf8 ausgeführt wird?
08:51 <webzwo0i> oha ups, bitte wende die mysql-befehle nicht an. vielleicht war ich ein bisschen zu schnell :-) muss erst mal was überprüfen
09:08 <webzwo0i> mh nein, sollte in Ordnung sein, bitte testen ... es wäre gut zu wissen, ob Sie die neueste Version oder etwas anderes ausgeführt haben und welche Plugins Sie aktiviert haben
09:47 <webzwo0i> Ich weiß nicht, ob Sie sich bei wikimedia kennen, aber wenn Sie herausfinden können, wer der Benutzer "Brian" ist, können Sie ihn fragen, welchen Browser er verwendet? das
Grund ist, dass ich sehen kann, was der Fehler ist, aber ich kann ihn nicht in meinem Browser auslösen (nur manuell, aber weil Sie ppl nicht feindlich sind, war es wahrscheinlich nicht eingeschaltet
Zweck)
09:49 <webzwo0i> (also haben wir wahrscheinlich zwei Fehler, einen serverseitigen und einen clientseitigen)

Die Informationen, die ich brauche, sind, wenn Ihre Datenbank utf8 oder utf8mb4 ist
Ich habe den fehlerhaften Änderungssatz extrahiert. Der Zeitschieber wird diese Überarbeitungen nicht umgehen, wenn Sie ihn nicht auch anwenden

mysql> update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS-iteration-planning:revs:7105";

Zusammen mit den Updates von oben sollte dies Ihr Pad wieder verwendbar machen

@ webzwo0i

Ja, ich habe bemerkt, dass Mutante mit dir gesprochen hat. Ich habe mich gerade entschlossen, auch das Github-Problem weiterzuverfolgen. Ich werde herausfinden, wer "Brian" ist und welchen Browser sie für Sie verwenden.

Die Speichertabelle ist also schon seit einiger Zeit utf8mb4. Es war utf8, aber wir haben aufgrund anderer Probleme im Juni auf utf8mb4 konvertiert. Speziell am 23. Juni 2015

https://github.com/ether/etherpad-lite/issues/2522#issuecomment-114441189 ;-)

Ich muss den Benutzer / Browser nicht herausfinden, ich kann den Fehler jetzt reproduzieren. Dankeschön!

Da Sie sich in der neuesten Version befinden, müssen Sie "charset": "utf8mb4" in settings.json in dbSettings einfügen. Dies ist jetzt in settings.json.template. Sie können mit überprüfen, ob dies erforderlich ist

SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';

Der Client (und möglicherweise die Verbindung?) sollte utf8mb4 anzeigen, wenn nicht Ihre Datenbanktabellen selbst 4 Byte utf8 speichern können, der Server jedoch keine 4 Byte utf8 und die Clientverbindung erwartet.
Dadurch werden Ihre alten Pads nicht repariert. Sie können jedoch alle Ihre Pads durchlaufen und mit bin / checkPad.js eine Vorstellung davon bekommen, wie viele und welche Pads ähnliche Probleme haben könnten. Abhängig von den Umständen kann es sehr einfach sein, Reparaturen durchzuführen (obwohl einige Zeichen beschädigt werden), wie im obigen Fall. Wenn es viele kaputte Pads gibt, kann es sinnvoll sein, dies zu automatisieren.

Der Grund, warum diese Probleme beim Schreiben nicht auftreten, ist, dass die meisten Websites den internen Cache von ueberDB für die Leistung verwenden. Dieser reine Javascript-Cache kennt Unicode vollständig. Sobald der Cache geleert oder das Etherpad neu gestartet wird, müssen die Einträge aus der Datenbank abgerufen werden.

Ich habe das Pad repariert, wie Sie es angewiesen haben. Interessant herauszufinden, dass 4 Fragezeichen hintereinander ein PAD so beschädigen würden. Und dass das beschädigte Änderungsset im Vergleich zur Spitze des Pads so alt wäre. Aber Ihre Erklärung macht Sinn, danke dafür.

Ich habe die Konfiguration auch mit "charset": "utf8mb4" aktualisiert.

Ich verfolge das Phabricator-Ticket bei wikimedia, habe dort aber kein Konto und poste es hier.

Ihr zweites kaputtes Pad kann auch repariert werden mit:

update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1120";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1254";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1216";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1108";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1106";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1200";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1300";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1400";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1500";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1600";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1700";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1800";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:1900";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:2000";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:2100";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:2200";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:2300";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives:revs:2400";
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:iOS_Retrospectives";

Die 4 Fragezeichen sind das Symptom, da die einzelnen Bytes in Vier-Byte-UTF8 nicht gültig sind. (In UTF8 werden nur die ersten 127 Zeichen als einzelne Bytes dargestellt, Multibyte-UTF8 verwendet wahrscheinlich Bytes über 0x7f). 4 Fragezeichen stehen also tatsächlich für eine 4-Byte-codierte UTF8-Zeichenfolge, die einen Codepunkt außerhalb der mehrsprachigen Grundebene darstellt (höchstwahrscheinlich ein Emoji :-D). In Javascript würden diese Codepunkte unter Verwendung der UTF16-Ersatzpaare codiert, die 2 16-Bit-Werte sind.

Das checkRep-Problem ist, dass wir in Changesets nicht nur die Zeichen, sondern auch die Länge der Änderung speichern. Die Funktion length () von Javascript zählt jedoch Ersatzpaare als 2, z. B. hat ein Emoji die Länge 2. Wenn mysql die Zeichenfolge eines Änderungssatzes in Fragezeichen dekodiert, ist unsere Darstellung eines Änderungssatzes nicht mehr gültig.

Das Ersetzen durch zwei Fragezeichen ist ein Hack, keine echte Lösung, da wir keine Ahnung haben, welchen Codepunkt der Benutzer zuerst eingegeben hat (aber solange sich der Wert im Cache von ueberDB befindet, können wir ihn von dort herausholen).

Es würde zu falschen Ergebnissen führen, wenn jemand tatsächlich vier Fragezeichen verwendet (unser Längenwert würde 4 anzeigen, wenn wir ihn durch 2 Fragezeichen ersetzen, erhalten wir im Gegenzug einen checkRep-Fehler). Wenn wir also ein Reparaturskript automatisieren würden, müssten wir dies überprüfen Wenn die Zeichenfolgenlänge nach dem Anwenden unserer Änderung dem Wert "wie viele Zeichen hinzugefügt werden" des Änderungssatzes entspricht.

Um das Problem zu umgehen, wenn jemand tatsächlich vier Fragezeichen verwendet und zusätzlich Punkte wie Emoji codiert, müssen wir auch die Position innerhalb des Dokuments verfolgen, an der wir die Fragezeichen ersetzen.

Beachten Sie auch, dass nicht jeder checkRep-Fehler durch eine fehlerhafte Codierung verursacht wird

Und natürlich hat das oben genannte funktioniert. GENIAL! Ich kann Ihnen nicht genug danken. Ich hoffe, dass dies mit dem Konfigurationsfix nicht wieder vorkommt.

Ich habe mich gefragt, ob das Debuggen, das Sie durchführen, übrigens manuell erfolgt. Abrufen und Vergleichen der Änderungssätze und ihrer Längen nacheinander manuell oder wenn Sie eine automatisiertere Methode haben. Ich nehme an, ich kann sowieso eine eigene erstellen, nur neugierig sein

<3 @ webzwo0i Danke Mann, du bist großartig

@ webzwo0i Ich habe in letzter Zeit eine

Der Fehler kann leicht reproduziert werden, indem ein neues Pad mit einem einzelnen Emoji (z. B. 🐼) erstellt und das Etherpad neu gestartet wird, siehe auch # 3340.

Update : Ab April 2019 bricht dieses einzelne Emoji selbst nach dem Neustart kein Pad mehr.

Ich wollte alle Pads überprüfen, also habe ich ein checkAllPads Tool hinzugefügt (siehe PR # 3342).

Der Fehler kann leicht reproduziert werden, indem ein neues Pad mit einem einzelnen Emoji (z. B. panda_face) erstellt und das Etherpad neu gestartet wird, siehe auch # 3340.

Ich kann das nicht reproduzieren und mache genau das, was oben beschrieben wurde. Ein Beispiel finden Sie unter https://etherpad.wikimedia.org/p/ohmy (ja, ich habe etherpad bereits mehrmals neu gestartet).

Wir hatten gerade einen Pad-Bruch mit diesem Fehler. Seltsamerweise findet checkPad,js kein Problem, und repairPad.js vollständig ausgeführt, ohne es zu beheben. Gibt es eine Möglichkeit festzustellen, welche Revision fehlerhaft ist?

EDIT: Ah, ich habe https://gist.github.com/marcelklehr/a78d293571e7f06e3cf9 gefunden, was mir den richtigen Weg zeigte. Gibt es eine Chance, dass dies in Etherpad selbst enthalten ist? Es war im Moment unendlich hilfreich, vielen Dank! (Ich musste jedoch console.log durch console.error ersetzen, um überhaupt Revisionsnummern zu sehen. Ich habe keinerlei Erfahrung mit nodeJS, aber ich konnte keinen anderen Weg finden, um die gesamte Protokollierung tatsächlich zu sehen. )

In der Tat hat es auch hier geholfen, " ???? durch ?? ersetzen". :) Scheint, als ob der letzte Änderungssatz jemand war, der ein Emoji einfügte (es endete mit $???? ).

Ich verstehe jedoch nicht, warum dies als "kleiner Fehler" eingestuft wird. Dieser Fehler führt zum Totalverlust eines Pads (bis jemand das /timeslider Ding bemerkt, das in unserem Fall eine Woche gedauert hat und selbst dann die Geschichte verloren geht).

Ich bin nicht zugewiesen, da es unwahrscheinlich ist, dass ich das beheben kann. FWIW, dieser Fehler scheint auf eine Einschränkung der easysync-Bibliothek zurückzuführen zu sein, von der ich spekuliere, dass sie nicht alle utf-8 unterstützt. (UTF-8 kann ein Zeichen als mehrere Bytes codieren, die jeweils die Länge einer Zeichenfolge in Javascript erhöhen, obwohl es sich nur um ein Zeichen handelt.)

- egal -: D.

FWIW, dieser Fehler scheint auf eine Einschränkung der easysync-Bibliothek zurückzuführen zu sein, von der ich spekuliere, dass sie nicht alle utf-8 unterstützt. (UTF-8 kann ein Zeichen als mehrere Bytes codieren, die jeweils die Länge einer Zeichenfolge in Javascript erhöhen, obwohl es sich nur um ein Zeichen handelt.)

Tatsächlich haben wir ständig Umlaute (äöü) in unseren Pads, die auch in UTF-8 Multibyte sind. Basierend auf dem, was oben gesagt wurde, denke ich, dass es sich tatsächlich um UTF-16 handelt - das, als es ursprünglich entworfen wurde, genau 2 Bytes pro Zeichen haben sollte (Codepoint, wirklich), aber jetzt, wo wir mehr als 2 ^ haben 16 Codepunkte gibt es einige, die 4 Bytes benötigen, wie Emojis. Und jetzt stimmt length() nicht mehr mit der Anzahl der Codepunkte überein, und alles wird verwirrt.

Vielleicht ist es eine bessere Lösung, Ersatzpaare (4-Byte-Codepunkte) sofort abzulehnen? Das würde es unmöglich machen, Etherpad mit Zeichen aus der Ergänzungsebene zu verwenden , aber das ist wahrscheinlich sowieso kaputt, wie es scheint? Und es sollte die DB schützen. Es scheint Möglichkeiten zu geben, in JS auf Ersatzpaare zu testen (aber ich habe keine Erfahrung mit modernem JavaScript).

Warum wurde das geschlossen? Meines Wissens erstickt Etherpad immer noch an Charakteren außerhalb des BMP. Ich musste kürzlich erneut ein Pad reparieren, das auf diese Weise kaputt gegangen war.

Ich habe es geschlossen, weil ich die Ausgabe 2014 geöffnet habe und mich nicht mehr dafür interessierte.

Nun, es ist immer noch ein offenes Problem für andere, also würde ich mich freuen, wenn Sie wieder öffnen könnten.

Vielen Dank! :) :)

Hat jemand ein Beispiel für ein Zeichen (eine Sequenz), das ein Pad zuverlässig bricht? Dies würde das Debuggen erleichtern, denke ich.

Die Easysync-Bibliothek beschreibt Text (und seine Breite) in Form von "Zeichen", war jedoch ein Produkt mit minimaler Lebensfähigkeit vor 10 Jahren. Heutzutage sollten wir wahrscheinlich in NFC-normalisierten UTF-8-Codepunkten denken.

Ich frage mich nur, ob wir das Problem möglicherweise lösen können, indem wir die ueberdb-Werte als binäre Blobs anstatt in einer sortierten Textspalte speichern.

Wenn wir derzeit versuchen, eine ungültige Byte-Sequenz utf8mb4 (denken Sie an einen Änderungssatz, der einen Teil eines Multibyte-Zeichens enthält) in eine utf8mb4 -Spalte einzufügen, gibt es nur zwei mögliche Ergebnisse: Entweder lehnt die Datenbank die ab Eingabe oder Client (oder Server) müssen die ungültigen "Zeichen" oder Bytes vorher entfernen (denken Sie: durch "?" ersetzen).

Durch die Verwendung einer binären Blob-Spalte würde sich die Datenbank nicht mehr darum kümmern, dass die Byte-Sequenz ungültig ist. Utf8mb4, sodass wir möglicherweise das Ersetzen von Zeichen vermeiden. Wenn easysync so codierungsunabhängig ist, wie ich es verstehe, könnte dies funktionieren (solange zwei Benutzer nicht gleichzeitig Multibyte-Zeichen AB und CD an derselben Position einfügen und diese als einzelne Änderungssätze A, C, B, D enden - in diesem order -, wodurch das zusammengeführte Ergebnis ungültig wird (utf8mb4).

PS: Ich habe gerade getestet, dass das Einfügen eines 4-Byte-UTF8-Zeichens wie 🍰 selbst kein Problem darstellt (obwohl: Ich habe noch nicht neu gestartet, was eine Erklärung sein könnte), daher gehe ich davon aus, dass der Fehler entweder Parallelität erfordert (was dazu führt, dass das Zeichen ist aufgeteilt in zwei oder mehr Änderungssätze, die für sich allein ungültig sind) oder es erfordert, dass ein Client einen Änderungssatz ausgibt, der einen Teil eines solchen Zeichens entfernt.

Hallo, wir haben dieses Problem auch bei vielen Pads.

Ich versuche alles und kann dies einfach nicht durch 🍰 ersetzen. Ich habe Neustarts versucht, verschiedene Datenbank-Backends (die richtig konfiguriert sind).

Kann jemand Schritte bereitstellen, um mit unserer moderneren Codebasis zu replizieren?

Wenn Sie die Rücktaste auf 🍰 drücken, wird der Gegenstand durch ersetzt, was offensichtlich blöd ist.

Für mich hat replace( value ,'????','??') bisher immer funktioniert. Ist aber seit ein paar Monaten nicht mehr passiert.

Ich habe eine aktualisierte Version von Check Pad Deltas beigefügt, die funktioniert. Wenn die Leute versuchen können, herauszufinden, ob dies bei diesem Problem hilfreich ist, würde ich es begrüßen.

Ich denke immer noch, dass das Grundproblem darin besteht, dass das Etherpad-Datenmodell in "Zeichen" und nicht in normalisierten UTF-8-Codepunkten denkt.

Wenn wir die Kernbibliothek nicht überarbeiten, wird dies niemals wirklich gelöst. Offensichtlich ist jede Minderung nützlich. Ich sage nur, dass es keine einfachen Lösungen gibt, die meiner Meinung nach garantiert 100% korrekt sind.

Sie wären überrascht, wie viele Editoren (und sehr beliebte bei Entwicklern) eine ähnliche Erfahrung wie Etherpad haben. Ich habe heute herumgespielt und einige verrückte Erfahrungen gemacht.

Ich habe eine aktualisierte Version von Check Pad Deltas beigefügt, die funktioniert. Wenn die Leute versuchen können, herauszufinden, ob dies bei diesem Problem hilfreich ist, würde ich es begrüßen.

Mit # 3717 (14ae2ee95094) in den Hauptzweig eingezogen.

Hallo, wir haben ein ähnliches Problem mit einem unserer Pads.
@ JohnMcLear leider hat die neueste Version von checkPadDeltas nicht geholfen: /

@gnd hast du eine öffentliche Instanz?

Können Sie die URL padId / export / etherpad drücken und die Etherpad-Datei abrufen?

Führen Sie die neueste Entwicklung aus?

Was ist Ihr Datenbank-Backend?

So viele Fragen, bitte geben Sie so viele Details wie möglich an

@ JohnMcLear
Ja, es ist eine öffentliche Instanz: https://pad.xpub.nl/p/CareCircle
Leider erhalte ich einen 502 Bad Gateway-Fehler beim Versuch, die .etherpad-Datei abzurufen
Wir führen die neueste Entwicklung (Git Pull Origin) auf NodeJS 12.16.3-1Nodesource1 aus, wobei das DB-Backend 10.3.22-MariaDB-0 + deb10u1 ist.

Ich bin heute verfügbar, um Ihnen bei jeder Art von Debugging zu helfen, die Sie möglicherweise durchführen möchten. Ich habe bereits die letzte Version von checkPadDeltas ausprobiert, sie hängt jedoch nur stundenlang nach dem Start. Dies ist die einzige Ausgabe, die es gibt:

Alle relativen Pfade werden relativ zum identifizierten Etherpad-Basisverzeichnis interpretiert: / opt / etherpad
[2020-05-05 00: 04: 12.330] [DEBUG] AbsolutePaths - Der relative Pfad "settings.json" kann in "/opt/etherpad/settings.json" umgeschrieben werden.
[2020-05-05 00: 04: 12.346] [DEBUG] AbsolutePaths - Der relative Pfad "credentials.json" kann in "/opt/etherpad/credentials.json" umgeschrieben werden.
Einstellungen geladen von: /opt/etherpad/settings.json
In /opt/etherpad/credentials.json wurde keine Anmeldeinformationsdatei gefunden. Ignorieren.
[2020-05-05 00: 04: 12.369] [INFO] -Konsole - Verwenden von Skin "no-skin" in dir: / opt / etherpad / src / static / skins / no-skin
[2020-05-05 00: 04: 12.371] [INFO] -Konsole - Sitzungsschlüssel geladen von: /opt/etherpad/SESSIONKEY.txt
[2020-05-05 00: 04: 12.541] [ERROR] -Konsole - Tabelle ist nicht mit Zeichensatz utf8 konfiguriert - Dies kann zu Abstürzen führen, wenn bestimmte Zeichen in Pads eingefügt werden
[2020-05-05 00: 04: 12.543] [INFO] -Konsole - RowDataPacket {Zeichensatzname: 'utf8mb4'} utf8

Alter, der Fehler ist in deinem Log!

[2020-05-05 00:04:12.541] [ERROR] console - table is not configured with charset utf8 -- This may lead to crashes when certain characters are pasted in pads
[2020-05-05 00:04:12.543] [INFO] console - RowDataPacket { character_set_name: 'utf8mb4' } utf8

Siehe: https://github.com/ether/etherpad-lite/issues/3959

@ JohnMcLear
unsere db hat

+ ---------------------------- + -------------------- ---- +
| DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME |
+ ---------------------------- + -------------------- ---- +
| utf8 | utf8_general_ci |
+ ---------------------------- + -------------------- ---- +

Während der Speichertisch hat

+ -------------------- +
| Zeichensatzname |
+ -------------------- +
| utf8mb4 |
+ -------------------- +

Also sollte ich mit konvertieren
ALTER DATABASE etherpad_lite_db CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

?

@ JohnMcLear

Die Fehlkonfiguration war zweifach, die Datenbank verwendete utf8 und utf8_general_ci, aber auch in settings.json wurde der Zeichensatz für die Datenbank als "utf8" festgelegt. Nachdem behoben wurde, dass alles auf utf8mb4 immer noch nicht geholfen hat und das betreffende Pad nicht geladen wird und das checkPadDeltas immer noch hängt:

Alle relativen Pfade werden relativ zum identifizierten Etherpad-Basisverzeichnis interpretiert: / opt / etherpad
[2020-05-05 13: 17: 43.443] [DEBUG] AbsolutePaths - Der relative Pfad "settings.json" kann in "/opt/etherpad/settings.json" umgeschrieben werden.
[2020-05-05 13: 17: 43.444] [DEBUG] AbsolutePaths - Der relative Pfad "credentials.json" kann in "/opt/etherpad/credentials.json" umgeschrieben werden.
Einstellungen geladen von: /opt/etherpad/settings.json
In /opt/etherpad/credentials.json wurde keine Anmeldeinformationsdatei gefunden. Ignorieren.
[2020-05-05 13: 17: 43.463] [INFO] -Konsole - Verwenden von Skin "no-skin" in dir: / opt / etherpad / src / static / skins / no-skin
[2020-05-05 13: 17: 43.464] [INFO] -Konsole - Sitzungsschlüssel geladen von: /opt/etherpad/SESSIONKEY.txt

@gnd Es ist ein GiGo-Problem. Sobald Sie Müll haben, kann er nicht mehr geändert werden. Jetzt wissen Sie nur noch, dass das Problem in Zukunft nicht mehr auftreten wird!

@gnd Es ist ein GiGo-Problem. Sobald Sie Müll haben, kann er nicht mehr geändert werden. Jetzt wissen Sie nur noch, dass das Problem in Zukunft nicht mehr auftreten wird!

Wäre repairPad.js nicht in der Lage, diese kaputten Pads zu reparieren?

Oh hi @caugner - leider nein ,paraturPad.js ist im Allgemeinen scheiße und funktioniert nicht wirklich. https://github.com/ether/etherpad-lite/blob/develop/bin/repairPad.js#L48

Das Beste, was ich vorschlagen kann, ist, den Text aus dem Pad zu ziehen und in ein neues Pad zu bringen.

@gnd Kann ich dir ein Skript zum Testen schreiben, um zu versuchen, den Text zu bekommen, wenn du willst?

bin/extractPadData.js mit einer Änderung der Ausgabe in stdout könnte hier ausreichend sein. 2 Minuten Ich werde eine extractPadText.js erstellen

@ JohnMcLear das wäre in der Tat sehr hilfreich)

Extrahieren

Verwenden Sie node bin/extractPadData.js $padid
Dann cat $padid.db | grep \"text\" | grep revNum | tail -1

Der Text ist das val.atext.text -Element. Sie können dies bei cli analysieren. Ich werde das als nächstes tun, wenn Sie es brauchen. Führen Sie diese Befehle vorerst aus, um sicherzustellen, dass Sie $ padid durch Ihre PadID ersetzen

Parsing

sudo apt-get install jq , um jq zu installieren, dann cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text , um nur den Text zu sehen.

So schreiben Sie den Pad-Text in eine Textdatei cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text > $padid.txt

Jetzt haben Sie den Pad-Text, den Sie einfach in eine Textdatei einfügen und importieren können, oder Sie setzen die Text-API oder was auch immer ...

Ich weiß, ob die Extraktion fehlschlägt, und ich werde einen anderen Ansatz in Betracht ziehen.

Die Extraktion läuft, ist jedoch ziemlich langsam. In der Datei CareCicle.db sehe ich die neueste Zeile bei Umdrehungen: 80 , während das Skript bereits 20 m lang ausgeführt wird. Das fragliche Pad hat über 12.000 Revisionen.

Oh man, das ist scheiße. Ich denke, es kann das pad -Objekt nach 80 Revisionen nicht erstellen. Es sollte nur ungefähr 30 Sekunden dauern, bis das Skript ausgeführt wird.

Der letzte Vorschlag wäre ein großer, die gesamte Datenbank zu sichern und an mich zu senden. Dann kann ich ein Skript schreiben, um herauszufinden, was Sie brauchen. Alternativ kann ich versuchen, hier ein Skript zu schreiben, aber es kann ein Hin und Her geben, damit es so funktioniert.

Hallo @JohnMcLear , das Skript ist endlich fertig. Ich habe keine Ahnung, warum es so lange gedauert hat (fast 40 Stunden). Wie auch immer, wenn ich es mir anschaue, scheint es mir, dass die gesamte Übung durchgeführt werden kann, indem die höchste Revision, die durch 100 teilbar ist, aus der Speichertabelle ausgewählt und der Text daraus extrahiert wird? In Zukunft mache ich das von Hand :) Vielen Dank für Ihre Hilfe

Genau das, aber unsere Benutzer sagen mir oft Bescheid, wenn ich davon ausgehe, dass sie Datenbankabfragen durchführen können, und versuche, dies zu vermeiden. Ich glaube, ich weiß, warum es übrigens so lange gedauert hat. Verwenden Sie MySQL @ Etherpad 1.8.3?

Ich verwende den neuesten Master von Git (nicht sicher, welche Version das ist)

Angenommen, MySQL ist ein bekannter Fehler, dass wir das Patch-Land heute haben werden.

ja sorry, es ist die neueste MariaDB - 10.3.22-MariaDB

@ JohnMcLear Es tut mir leid, dieses Ticket zu

Nein, aber installieren Sie einfach Problem zu beheben

Übrigens ist die neue Logik zum Speichern von zusätzlichem Text enthalten, daher sollte diese geschlossen werden. Wenn jedoch ein Problem auftritt, erstellen Sie bitte ein neues Problem und beziehen Sie sich auf dieses. Ich möchte mich von Fall zu Fall mit jeder einzelnen Problemursache befassen, mit dem Hauptziel, eine automatisierte Logik zu erstellen, um ein Pad bei erkannter Beschädigung in Echtzeit wiederherzustellen. Das ist der Traum, denn Korruption ist unvermeidlich.

Dies ist eine Meldung für Benutzer, die kürzlich darauf zugreifen (beim Upgrade von älteren Versionen von Etherpad).

Heute habe ich einen Etherpad-Service von 1.6.3 auf 1.8.6 aktualisiert (was für eine Änderung !!!!! Glückwunsch an alle Entwickler)

Ich hatte Probleme mit einem Pad, die Prüfer (checkPad, checkAllPads usw.) konnten es nicht erkennen (oder ich weiß sowieso nicht, wie man den Knoten gut ausführt).

Ich habe überprüft, ob charset in meiner settings.json utf8mb4 (siehe letzte Version in settings.json.template ).

  "dbType" : "mysql",
  "dbSettings" : {
    "user":     "etherpaduser",
    "host":     "localhost",
    "port":     3306,
    "password": "PASSWORD",
    "database": "etherpad_lite_db",
    "charset":  "utf8mb4"
  },

Für den Fall https://pad.example.com/p/my-broken-pad habe ich

mysql
update `store` set `value` = replace(`value`,'????','??') where `key` like "pad:my-broken-pad"

und es hat wieder funktioniert: tada :: einhorn :: funkelt:

Diese Lösung war oben (ich habe eine +1 auf frühere Nachrichten mit der Lösung gesetzt, um sie zu finden), aber ich wollte es klarer haben

Ich denke, eine Sache, die wir hier tun könnten, ist nach ???? in Pad-Inhalt und geben Sie eine Warnung, die eine vorgeschlagene Lösung enthält. @ pedro-nonfree bitte könntest du einen Patch an checkPad.js senden oder so, dann würde ich das gerne zusammenführen :)