Etherpad-lite: Erreur non interceptée: échec de l'assertion: ensemble de modifications non valide (échec de checkRep)

Essayez la dernière branche de développement et faites-nous savoir si cela se produit toujours

Ce n'est pas anodin car cela se produit par hasard sur le serveur prod avec de nombreux utilisateurs et je ne peux pas le reproduire.
Je ne peux tester que si les coussinets cassés restent cassés pendant le développement, si cela aide.

Oui s'il vous plaît

Je vais faire copier la base de données sur dev la semaine prochaine. Fera rapport dès que possible. Merci pour la réponse rapide.

Malheureusement, passer au développement n'a pas réparé les coussinets endommagés. Fait intéressant, le déplacement des serveurs (simple exportation / importation SQL) a "réparé" l'un des tampons. Cela fonctionne sur le nouveau serveur (même sur la version 1.3.0) mais les autres pads endommagés ne le font pas. Toujours la même erreur.

C'est un bug vraiment étrange et les pads semblent parfois simplement "s'auto-réparer" même sur PROD et sans aucun changement de notre part.

En théorie, ce problème ne devrait pas se produire du tout car les mauvaises données ne devraient jamais trouver leur chemin maintenant.

Je peux laisser cela ouvert et s'il se produit sur de nouvelles données, nous pouvons essayer de le résoudre.

Que voulez-vous dire par «données fraîches»? Dois-je mettre PROD en développement et essayer d'obtenir de nouvelles plaquettes cassées?

Hrm, ce serait potentiellement douloureux ... Peut-être attendre la 1.4 qui devrait sortir dans quelques semaines maximum.

On pourrait faire ça. Merci beaucoup.

J'ai aussi ce problème, avec le même hasard étrange. J'ai mis à jour vers etherpad-lite 1.4 et il est toujours là. URL de l'un des pads http://etherpad.usabilidoido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4

Je suis actuellement en train de passer à la version 1.4 et j'espère que je vais vivre avec la nouvelle version, afin que je puisse vérifier si de nouveaux défauts apparaissent dans de nouvelles plaquettes après avoir exécuté la nouvelle version.

@usabilidoido vous pouvez dire à vos utilisateurs d'exporter-importer le pad. Vous pouvez accéder aux contrôles en ajoutant / timeslider à l'url comme ceci: http://etherpad.usabilidoido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4 / timeslider

Exportez au format HTML, puis importez-les dans un nouveau pad.

Je rencontre ce problème dans la version 1.4. Sur les pads cassés, la ligne de commande affiche [WARN] client - Uncaught TypeError: Cannot read property 'length' of undefined lorsque le navigateur affiche l'erreur Failed assertion .

Pointe du chapeau à @ Ra1d3n pour la solution de contournement / timeslider. Heureux de voir que le contenu des pads y est toujours accessible.

C'est juste une intuition, mais si vous le souhaitez, essayez avec la branche expérimentale try/client-init-remove-checkRep je viens de créer. (C'est généralement une chose dangereuse à faire, mais ça vaut le coup d'essayer, je pense.)

J'ai tout mis à niveau vers la version 1.4. et hier, nous avons eu à nouveau un tampon cassé. Peut-être encore un qui a éclaté avant la mise à jour, mais je ne suis pas sûr. Je vais continuer à chercher.

@marcelklehr Malheureusement, je ne peux pas déplacer le serveur de production vers une version _dangerous_. Et je ne peux pas mettre en miroir les demandes sur un serveur secondaire car je n'ai pas les ressources. : - /

Désolé, je n'ai pas été clair: ne lancez pas try/client-init-remove-checkRep en production, mais essayez d'accéder aux pads cassés avec etherpad fonctionnant sur cette branche.

J'ai supprimé checkRep dans cette branche, car je soupçonne que la normalisation peut ne pas fonctionner correctement dans certains cas. Donc, quand un pad cassé fonctionne sur cette branche sans aucun problème, nous devons revoir cette méthode.

@marcelklehr Je viens de le faire, et malheureusement cela n'a pas aidé.

Processus:

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

J'ai confirmé que le changement est en fait dans le système de fichiers. (le commentaire et la nouvelle ligne sont là) L'erreur est toujours la même.

J'ai eu l'erreur mentionnée par @ericpedia , et cela ne s'est pas produit sur des pads autres que celui corrompu.

console sur serveur:

[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' }

Lorsque je tue le serveur, le message s'affiche dans le client, également:

Je pourrais peut-être vous donner une importation SQL du tampon cassé, mais vous auriez besoin de me dire exactement ce dont vous avez besoin extrait de la base de données en premier. :-)

Le contenu réel du pad serait très utile, donc ce serait la clé db pad:<PADID> (http://etherpad.org/doc/v1.4.0/#index_pad_padid) et peut-être quelques-unes des dernières révisions.

Je pense que je me rapproche:

checkPad dit:

$ 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

Une application non concordante dans tous les cas signifie que l'ensemble de modifications en question attendait un caractère de moins que ce qui est réellement présent (donc, un caractère inattendu). Après avoir examiné le db dump, j'ai découvert que tous ces ensembles de modifications suivent une révision avec un texte attaché (toutes les révisions n'incluent pas le contenu complet du pad, mais seulement le delta, cependant, de temps en temps pour des raisons de performances, le contenu complet sont attachés).

Vraisemblablement, quelque chose a mal tourné avec cette méta propriété soit lors du stockage de la révision, soit lors de la création du texte actuel pour un nouveau client de pad.

Je viens de réécrire checkPad pour utiliser le texte calculé au lieu de celui mis en cache et le pad passe. Même les extraits en cache sont corrects! Cela me fait penser qu'il y a un bogue dans un algorithme qui calcule le texte complet pour les clients_vars!

Beau travail jusqu'ici Marcel. On dirait que vous êtes sur le point de résoudre ce problème.

Ah, ce n'est pas le générateur client_vars. L'algorithme responsable de la création du texte en cache est rompu.

@ Ra1d3n En guise de correctif rapide, vous pouvez raviver vos pads cassés en supprimant la propriété meta atext de toutes les révisions clés (où revNo % 100 == 0 ). La "réinsertion" de tous les enregistrements liés à un tampon cassé a été signalée comme un correctif pour des problèmes similaires il y a longtemps - maintenant nous savons pourquoi cela fonctionne :)

@marcelklehr Est-ce que cela

J'ai apporté quelques modifications au script checkPad. Voir ici: # 1653
Mais c'est plus un sale hack. Si mon script résout ce problème, j'écrirai un script pour réparer les pads

Cool, j'ai hâte d'y être. À l'heure actuelle, nous n'avons qu'un seul tampon cassé par semaine, je suis donc enclin à attendre une solution appropriée. :-) Merci.

Oui, je pensais à un scénario.

Ainsi, la différence entre le texte a calculé et celui mis en cache montre que: "концертов" s'est en quelque sorte transformé en "ко цертов". Dans une autre révision, "з" a également été transformé en " " ...

Je ne sais pas de quoi il s'agit. Ces caractères sont dans le BMP Unicode, afaik, donc je ne sais pas ce qui leur est arrivé.

Les mutations dans le pad de @ Ra1d3n se produisent dans les révisions clés 4900, 11400, 12300 et 13600 (chaque 100e tour est un tour clé, ce qui signifie qu'il mettra en cache le contenu complet du pad). De plus, le AttributedText stocké dans l'enregistrement de pad est également corrompu. Toutes les autres révisions clés sont correctes. (analysé avec ce script )

Les caractères semblent complètement aléatoires. Rien ne ressort, vraiment. Je ne vois pas de modèle.

Je soupçonne que quelque chose ne va pas lors du stockage du AttributedText dans la base de données. Puisque parfois le pad récupère entre les révisions de clé cassées, je suppose que le texte stocké en mémoire est bon. Parfois, quand il est stocké dans la base de données, il est corrompu d'une manière ou d'une autre. Si les auteurs continuent à éditer le document jusqu'à ce que la prochaine révision de clé soit créée et que cette révision ne finisse pas par être corrompue, alors personne ne remarquera rien.
Cependant, si le serveur s'arrête _avant_ et réussit à enregistrer dans la base de données le AText valide conservé en mémoire, le pavé sera cassé au prochain démarrage du serveur.

@marcelklehr Nous avons eu un crash et une récupération d'Etherpad plusieurs fois à cause d'un plugin qui n'était pas bien codé, est-ce que cela pourrait être la cause? Etrange que ce ne soit qu'une seule lettre corrompue à chaque fois.

J'ai créé un script pour réinsérer toute la valeur de base de données d'un pad. Sur mes blocs cassés, le script n'a pas fonctionné.
@ Ra1d3n Vous pouvez télécharger le script ici: https://github.com/Gared/etherpad-lite/blob/pad-repair-script/bin/repairPad.js
Assurez-vous que votre instance Etherpad n'est pas en cours d'exécution pendant que vous exécutez ce script.

@Gared D'où les valeurs de votre script? Je recommande de travailler sur mon fork de checkPad, en le peaufinant pour insérer les valeurs AttributedText recalculées dans la base de données.

@ Ra1d3n Les crashs d'Etherpad sont peu susceptibles de provoquer une corruption des données, je dirais.

@marcelklehr Cela a probablement rendu le problème plus visible, car la valeur de mémoire correcte a été perdue pour nous dans ces cas.

@marcelklehr Ce script est une dérivation du script extractPadData. Les valeurs et les clés sont chargées dans la fonction ci-dessus. Ce sont toutes les touches d'un pad.

Le script repairPad.js de @Gared corrige mes pads cassés. Y a-t-il une chance que ce correctif soit incorporé dans la prochaine version d'Etherpad-lite?

Bien sûr, envoyez simplement une demande d'extraction avec elle ou demandez à @Gared de

Demande de tirage ouverte # 2210

Mon etherpad fonctionne sur 1.4.1 et j'ai 3 fois le même problème décrit ci-dessus: le pad ne peut pas se charger mais / timeslider fonctionne bien.
2 d'entre eux sont maintenant réexécutés sans rien faire.
Sur le troisième pad, j'ai essayé sans succès le repairPad.js. Son url est: +1: http://portail.univ-lille1.fr/etherpad/link.jsp?groupID=g.jfobkKVrkydeTwLY&padID=SES_Grp8_Macroeconomie (vous devez cliquer sur "utilisez le pad avec l'invitexy" pour accéder à le paditself.

Peut-être y a-t-il un changeset avec une valeur anormale qui n'est pas prise en compte par repairPad ou y a-t-il une nouvelle version de reparPad.js que je n'ai pas vue sur git?

Nous pensons avoir une solution à ce problème maintenant. Veuillez tirer développer et tester :) Merci!

Bonjour, nous venons de faire cela. Nous exécutons 1.5.7, c'est la dernière version publiée. Le backend est une base de données MySQL. Je n'ai aucune indication sur les actions des utilisateurs qui pourraient avoir causé cela.

Pad en question: https://etherpad.wikimedia.org/p/iOS-iteration-planning

Récupérer les données du pad via l'astuce du curseur temporel fonctionne bien. Cependant, le tampon ne se chargera jamais.

Tout ce qui se trouve dans la base de données peut être vidé et fourni pour le débogage si cela aide.

salut, j'ai eu cette discussion le matin.
08:47 <webzwo0i> mutante: j'ai débogué le pad. vous ne devriez normalement pas faire cela, mais si vous avez une sauvegarde de base de données (et après avoir fait export / etherpad pour avoir une sauvegarde de
le pad), vous pouvez modifier trois entrées de base de données et le pad devrait à nouveau fonctionner correctement. les trois commandes mysql sont

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> pouvez-vous vérifier si votre base de données exécute utf8mb4 charset ou utf8?
08:51 <webzwo0i> Oh, s'il vous plaît, n'appliquez pas les commandes mysql. peut-être que j'étais un peu trop rapide :-) je dois d'abord vérifier quelque chose
09:08 <webzwo0i> mh non ça devrait aller, veuillez tester ... il serait bon de savoir si vous avez exécuté la dernière version ou autre chose et quels plugins vous avez activés
09:47 <webzwo0i> Je ne sais pas si vous vous connaissez chez wikimedia mais si vous pouvez savoir qui est l'utilisateur "Brian", pourriez-vous lui demander quel navigateur il utilise? la
la raison est que je peux voir quel est le bogue, mais je ne peux pas le déclencher dans mon navigateur (seulement manuellement, mais parce que vous n'êtes pas hostile, il ne l'était probablement pas
objectif)
09:49 <webzwo0i> (nous avons donc probablement deux bogues, un côté serveur et un côté client)

les informations dont j'ai besoin sont si votre base de données est utf8 ou utf8mb4
J'ai extrait l'ensemble de modifications incriminé, le timelider ne fonctionnera pas pour contourner ces révisions si vous ne les appliquez pas également

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

avec les mises à jour ci-dessus, cela devrait rendre votre pad réutilisable à nouveau

@ webzwo0i

Ouais, j'ai remarqué que le mutante t'a parlé. J'ai juste décidé de suivre également le problème de github. Je vais trouver qui est "Brian" et quel navigateur ils utilisent pour vous.

Ainsi, la table de stockage est utf8mb4 depuis un certain temps maintenant. C'était utf8 mais nous avons converti en utf8mb4 en raison d'un ensemble différent de problèmes en juin.

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

pas besoin de connaître l'utilisateur / navigateur, je peux reproduire le bug maintenant. Je vous remercie!

Comme vous utilisez la dernière version, vous devez insérer "charset": "utf8mb4" dans settings.json à l'intérieur de dbSettings. C'est maintenant dans settings.json.template. Vous pouvez vérifier si cela est nécessaire avec

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

client (et peut-être connexion?) devrait indiquer utf8mb4, sinon vos tables de base de données sont capables de stocker 4 octets utf8 mais le serveur n'attend pas 4 octets utf8 pour la connexion client.
Cela ne répare pas vos anciennes électrodes. Vous pouvez cependant parcourir tous vos pads et utiliser bin / checkPad.js pour avoir une idée du nombre et des pads qui pourraient avoir des problèmes similaires. Selon les circonstances, il peut être très facile à réparer (bien que certains caractères soient cassés) comme dans le cas ci-dessus. S'il y a beaucoup de coussinets cassés, il peut être judicieux d'automatiser cela.

La raison pour laquelle ces problèmes n'apparaissent pas lorsque les gens écrivent réellement est que la plupart des sites utilisent le cache interne d'ueberDB pour les performances. Ce cache pur javascript est totalement conscient d'Unicode. Dès que le cache est vidé ou que etherpad est redémarré, il doit obtenir les entrées de la base de données.

J'ai réparé le coussin comme vous l 'avez indiqué. Intéressant de découvrir que 4 points d'interrogation consécutifs corrompraient un PAD de cette manière. Et que le changeset corrompant serait si ancien par rapport à la pointe du pad. Mais votre explication a du sens, merci pour cela.

J'ai également mis à jour la configuration avec "charset": "utf8mb4".

Je suis le ticket phabricator sur wikimedia mais je n'ai pas de compte là-bas alors je le poste ici

Votre deuxième coussin cassé peut également être réparé en utilisant:

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";

Les 4 points d'interrogation sont le symptôme car, iirc, les octets uniques en UTF8 à quatre octets ne sont pas UTF8 valides. (En UTF8, seuls les 127 premiers caractères sont représentés sous forme d'octets uniques, l'UTF8 multi-octets utilise probablement des octets au-dessus de 0x7f). Donc, 4 points d'interrogation représentent en fait une chaîne UTF8 codée sur 4 octets, qui représente un point de code en dehors du plan multilingue de base (très probablement un emoji :-D). En Javascript, ces points de code seraient encodés en utilisant les paires de substitution UTF16, qui sont 2 valeurs de 16 bits.

Le problème de checkRep est que dans les changesets, nous stockons non seulement les caractères mais aussi la longueur du changement. La fonction length () de Javascript, cependant, compte les paires de substitution comme 2, donc par exemple un emoji a une longueur de 2. Quand mysql décode la chaîne d'un changeset en points d'interrogation, notre représentation d'un changeset n'est plus valide.

Le remplacer par deux points d'interrogation n'est pas une vraie solution car nous n'avons aucune idée du point de code que l'utilisateur a entré en premier lieu (mais tant que la valeur est dans le cache d'ueberDB, nous pourrions la sortir de là).

cela produirait des résultats erronés si quelqu'un utilisait réellement quatre points d'interrogation (notre valeur de longueur indiquerait 4, si nous la remplaçons par 2 points d'interrogation, nous obtiendrions une erreur checkRep en retour) donc si nous automatiserions un script de réparation, nous aurions besoin de vérifier si la longueur de la chaîne après l'application de notre modification est conforme à la valeur "combien de caractères sont ajoutés" du jeu de modifications.

pour contourner le problème si quelqu'un a réellement utilisé quatre points d'interrogation et en plus des points de code comme emoji, nous devons également suivre la position à l'intérieur du document où nous remplaçons les points d'interrogation.

Notez également que toutes les erreurs checkRep ne sont pas causées par un encodage cassé

Et bien sûr, ce qui précède a fonctionné. IMPRESSIONNANT! Je ne vous remercierai jamais assez. J'espère qu'avec le correctif de configuration en place, cela ne se reproduira plus.

Je me demandais si le débogage que vous faites est manuellement btw. Obtenir et comparer les ensembles de modifications et leurs longueurs un par un manuellement ou si vous disposez d'un moyen plus automatisé de le faire. Je suppose que je peux de toute façon créer un des miens, juste être curieux

<3 @ webzwo0i Merci mec, vous êtes génial

@ webzwo0i J'ai fait pas

L'erreur peut facilement être reproduite en créant un nouveau pad avec un seul emoji (par exemple 🐼) et en redémarrant etherpad, voir aussi # 3340.

Mise à jour : Depuis avril 2019, cet emoji unique lui-même ne casse pas un pad, même après le redémarrage.

Je voulais vérifier tous les pads, j'ai donc ajouté un outil checkAllPads (voir PR # 3342).

L'erreur peut facilement être reproduite en créant un nouveau pad avec un seul emoji (par exemple panda_face) et en redémarrant etherpad, voir aussi # 3340.

Je ne peux pas reproduire cela, en faisant exactement ce que décrit ci-dessus. Voir https://etherpad.wikimedia.org/p/ohmy pour un exemple (oui, j'ai déjà redémarré etherpad plusieurs fois)

Nous venons de faire une pause avec cette erreur également. Curieusement, checkPad,js ne trouve aucun problème, et repairPad.js se termine sans le réparer. Existe-t-il un moyen de déterminer quelle révision est en faute?

EDIT: Ah, j'ai trouvé https://gist.github.com/marcelklehr/a78d293571e7f06e3cf9 qui m'a indiqué le bon chemin. Une chance que cela puisse être inclus dans etherpad lui-même? Cela a été infiniment utile en ce moment, merci beaucoup! (Cependant, j'ai dû remplacer console.log par console.error pour voir même les numéros de révision. Je n'ai aucune expérience de nodeJS, mais je ne pouvais pas trouver une autre façon de voir réellement toute la journalisation. )

En effet, faire le "remplacer ???? par ?? " a également aidé ici. :) On dirait que le dernier ensemble de modifications était quelqu'un insérant un emoji (il s'est terminé par $???? ).

Cependant, je ne comprends pas pourquoi cela est classé comme "bug mineur". Ce bogue conduit à la perte totale d'un pad (jusqu'à ce que quelqu'un remarque la chose /timeslider , qui a pris une semaine dans notre cas, et même alors l'histoire est perdue).

Non affecté moi-même, car il est peu probable que je parvienne à résoudre ce problème. FWIW, ce bogue semble être dû à une limitation de la bibliothèque easysync, qui, je suppose, ne prend pas en charge tous les utf-8. (UTF-8 peut encoder un caractère sous forme de plusieurs octets, qui ajoutent chacun à la longueur d'une chaîne en javascript, même s'il ne s'agit que d'un caractère.)

- tant pis -: D

FWIW, ce bogue semble être dû à une limitation de la bibliothèque easysync, qui, je suppose, ne prend pas en charge tous les utf-8. (UTF-8 peut encoder un caractère sous forme de plusieurs octets, qui ajoutent chacun à la longueur d'une chaîne en javascript, même s'il ne s'agit que d'un caractère.)

En fait, nous avons tout le temps des trémas (äöü) dans nos pads, qui sont également multi-octets en UTF-8. Sur la base de ce qui a été dit ci-dessus, je pense que le problème concerne en fait l'UTF-16 - qui, lorsqu'il était initialement conçu, était censé avoir exactement 2 octets par caractère (point de code, vraiment), mais maintenant que nous en avons plus de 2 ^ 16 codepoints il y en a qui ont besoin de 4 octets, comme les emojis. Et maintenant length() ne correspond plus au nombre de points de code, et tout devient confus.

Alors peut-être qu'une meilleure solution est de rejeter carrément toutes les paires de substitution (points de code 4 octets)? Cela rendrait impossible l'utilisation d'Etherpad avec des caractères du plan supplémentaire , mais cela semble probablement cassé de toute façon? Et cela devrait protéger la base de données. Il semble y avoir des moyens de tester des paires de substitution dans JS (mais je n'ai aucune expérience en JavaScript moderne).

Pourquoi cela a-t-il été fermé? A ma connaissance, Etherpad s'étouffe toujours avec des personnages en dehors du BMP. Récemment, j'ai encore dû réparer manuellement un tampon qui s'était cassé de cette façon.

Je l'ai fermé parce que j'ai ouvert le numéro 2014 et que cela ne m'intéressait plus.

Eh bien, c'est toujours un problème ouvert pour les autres, alors j'apprécierais si vous pouviez rouvrir.

Merci! :)

Quelqu'un a-t-il un exemple de caractère (séquence) qui casse un pad de manière fiable? Cela faciliterait le débogage, je suppose.

La bibliothèque Easysync décrit le texte (et sa légèreté) en termes de «caractères», mais c'était un produit minimum viable depuis 10 ans. De nos jours, nous devrions probablement penser en termes de points de code UTF-8 normalisés NFC.

Je me demande simplement, pourrions-nous être en mesure de résoudre le problème en stockant les valeurs ueberdb sous forme de blobs binaires plutôt que dans une colonne de texte assemblée?

Actuellement, si nous essayons de mettre une séquence d'octets qui n'est pas valide utf8mb4 (pensez: un changeset qui contient une partie d'un caractère multi-octets) dans une colonne utf8mb4 , il n'y a que deux résultats possibles: soit la base de données refuse le entrée, ou le client (ou serveur) doit supprimer (pensez: remplacer par "?") les "caractères" ou octets non valides avant.

En utilisant une colonne blob binaire, la base de données ne se soucierait plus que la séquence d'octets soit invalide utf8mb4, nous pourrions donc éviter le remplacement de caractères. Si easysync est aussi indépendant de l'encodage que je comprends, cela pourrait fonctionner (tant que deux utilisateurs n'insèrent pas simultanément des caractères multi-octets AB et CD à la même position et qu'ils finissent en tant que changements individuels A, C, B, D - dans ce order -, rendant le résultat fusionné invalide utf8mb4).

PS: Je viens de tester que l'insertion d'un caractère UTF8 de 4 octets comme 🍰 n'est pas un problème en soi (bien que: je n'ai pas encore redémarré, ce qui peut être une explication), donc je suppose que le bogue nécessite soit la concurrence (conduisant au caractère étant divisé en deux ou plusieurs ensembles de modifications qui ne sont pas valides par eux-mêmes) ou il faut qu'un client émette un ensemble de modifications qui supprime une partie d'un tel caractère.

Salut, nous rencontrons également ce problème sur de nombreux pads.

J'essaye tout et je ne peux pas le remplacer par 🍰, j'ai essayé des redémarrages, différents backends de base de données (qui sont correctement configurés).

Quelqu'un peut-il fournir des étapes pour répliquer avec notre base de code plus moderne?

Frapper le retour arrière sur 🍰 remplace l'élément par , ce qui est évidemment nul.

Pour moi, replace( value ,'????','??') a toujours fonctionné jusqu'à présent. Cela ne s'est pas produit depuis quelques mois.

J'ai inclus une version mise à jour de Check Pad Deltas qui fonctionne, si les gens peuvent essayer de voir si cela aide lorsqu'ils rencontrent ce problème, je l'apprécierais.

Je pense toujours que le problème de base est que le modèle de données Etherpad pense en termes de "caractères" et non de points de code UTF-8 normalisés.

À moins que nous ne retravaillions la bibliothèque principale, cela ne sera jamais vraiment résolu. De toute évidence, toute atténuation est utile. Je dis simplement qu'il n'y a pas de solutions faciles à garantir à mon avis correctes à 100%.

Vous seriez surpris de voir combien d'éditeurs (et très populaires auprès des développeurs) ont une expérience similaire à celle d'Etherpad. En jouant aujourd'hui, j'ai eu des expériences folles.

J'ai inclus une version mise à jour de Check Pad Deltas qui fonctionne, si les gens peuvent essayer de voir si cela aide lorsqu'ils rencontrent ce problème, je l'apprécierais.

Tiré dans la branche principale avec # 3717 (14ae2ee95094).

Bonjour, nous rencontrons un problème similaire avec l'un de nos pads.
@JohnMcLear, malheureusement, la dernière version de checkPadDeltas n'a pas aidé: /

@gnd avez-vous une instance publique?

Pouvez-vous frapper l'url padId / export / etherpad et obtenir le fichier .etherpad?

Exécutez-vous le dernier développement?

Quel est votre backend de base de données?

Tant de questions, veuillez fournir le plus de détails possible

@JohnMcLear
Oui, c'est une instance publique: https://pad.xpub.nl/p/CareCircle
Malheureusement, j'obtiens une erreur 502 Bad Gateway en essayant d'obtenir le fichier .etherpad
Nous exécutons le dernier développement (git pull origin) sur nodejs 12.16.3-1nodesource1, le backend db étant 10.3.22-MariaDB-0 + deb10u1.

Je suis disponible aujourd'hui pour vous aider avec tout type de débogage que vous voudrez peut-être faire. J'ai déjà essayé la dernière version de checkPadDeltas, mais elle se bloque pendant des heures après le démarrage. C'est le seul résultat qu'il donne:

Tous les chemins relatifs seront interprétés par rapport au répertoire de base Etherpad identifié: / opt / etherpad
[2020-05-05 00: 04: 12.330] [DEBUG] AbsolutePaths - Le chemin relatif "settings.json" peut être réécrit en "/opt/etherpad/settings.json"
[2020-05-05 00: 04: 12.346] [DEBUG] AbsolutePaths - Le chemin relatif "credentials.json" peut être réécrit en "/opt/etherpad/credentials.json"
paramètres chargés depuis: /opt/etherpad/settings.json
Aucun fichier d'informations d'identification trouvé dans /opt/etherpad/credentials.json. Ignorer.
[2020-05-05 00: 04: 12.369] [INFO] console - Utilisation du skin "no-skin" dans dir: / opt / etherpad / src / static / skins / no-skin
[2020-05-05 00: 04: 12.371] [INFO] console - Clé de session chargée depuis: /opt/etherpad/SESSIONKEY.txt
[2020-05-05 00: 04: 12.541] [ERROR] console - la table n'est pas configurée avec charset utf8 - Cela peut entraîner des plantages lorsque certains caractères sont collés dans les pads
[2020-05-05 00: 04: 12.543] [INFO] console - RowDataPacket {character_set_name: 'utf8mb4'} utf8

Mec, l'erreur est dans ton journal!

[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

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

@JohnMcLear
notre base de données a

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

Alors que la table du magasin a

+ -------------------- +
| character_set_name |
+ -------------------- +
| utf8mb4 |
+ -------------------- +

Alors devrais-je convertir en utilisant
ALTER DATABASE etherpad_lite_db CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

?

@JohnMcLear

La mauvaise configuration était double, la base de données utilisait utf8 et utf8_general_ci, mais aussi dans settings.json, le jeu de caractères de la base de données était défini sur "utf8". Après avoir résolu tout cela sur utf8mb4 n'a toujours pas aidé, et le pad en question ne se charge pas, et checkPadDeltas se bloque toujours:

Tous les chemins relatifs seront interprétés par rapport au répertoire de base Etherpad identifié: / opt / etherpad
[2020-05-05 13: 17: 43.443] [DEBUG] AbsolutePaths - Le chemin relatif "settings.json" peut être réécrit en "/opt/etherpad/settings.json"
[2020-05-05 13: 17: 43.444] [DEBUG] AbsolutePaths - Le chemin relatif "credentials.json" peut être réécrit en "/opt/etherpad/credentials.json"
paramètres chargés depuis: /opt/etherpad/settings.json
Aucun fichier d'informations d'identification trouvé dans /opt/etherpad/credentials.json. Ignorer.
[2020-05-05 13: 17: 43.463] [INFO] console - Utilisation du skin "no-skin" dans le répertoire: / opt / etherpad / src / static / skins / no-skin
[2020-05-05 13: 17: 43.464] [INFO] console - Clé de session chargée depuis: /opt/etherpad/SESSIONKEY.txt

@gnd C'est un problème GiGo. Une fois que vous avez des déchets, ils ne peuvent pas être modifiés. Maintenant, tout ce que vous savez, c'est que le problème n'apparaîtra plus à l'avenir!

@gnd C'est un problème GiGo. Une fois que vous avez des déchets, ils ne peuvent pas être modifiés. Maintenant, tout ce que vous savez, c'est que le problème n'apparaîtra plus à l'avenir!

Est-ce que repairPad.js pourrait pas réparer ces tampons cassés?

Oh salut @caugner - malheureusement non, repairPad.js est généralement nul et ne fonctionne pas vraiment. https://github.com/ether/etherpad-lite/blob/develop/bin/repairPad.js#L48

La meilleure chose que je puisse suggérer est de retirer le texte / texte du bloc-notes et de l'amener dans un nouveau bloc-notes.

@gnd Je peux vous écrire un script à tester pour essayer d'obtenir le texte si vous le souhaitez?

bin/extractPadData.js avec un changement de sortie vers stdout pourrait être suffisant ici.

@JohnMcLear, ce serait vraiment très utile)

Extraction

Utilisez node bin/extractPadData.js $padid
Puis cat $padid.db | grep \"text\" | grep revNum | tail -1

Le texte est l'élément val.atext.text , vous pouvez json analyser ceci à cli .. Je le ferai ensuite si vous en avez besoin .. Pour l'instant, effectuez ces commandes en vous assurant de remplacer $ padid par votre PadID

Analyse

sudo apt-get install jq pour installer jq puis cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text pour ne voir que le texte.

Pour écrire le texte du Pad dans un fichier texte cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text > $padid.txt

Maintenant que vous avez le texte du pad, vous pouvez simplement le mettre dans un fichier texte et l'importer ou ou vous définir l'API Text ou autre ...

Laissez-moi savoir si l'extraction échoue et je considérerai une autre approche.

L'extraction est en cours, mais elle est assez lente. Dans le fichier CareCicle.db, je vois la dernière ligne à revs: 80 , alors que le script fonctionne déjà pendant 20m. Le bloc en questions a plus de 12 000 révisions.

Oh mec, ça craint ... Je suppose qu'il ne peut pas construire l'objet pad après 80 révisions ... Cela ne devrait prendre que 30 secondes environ pour que le script s'exécute.

la dernière suggestion serait une grande, de vider la base de données entière et de me l'envoyer, puis je peux écrire un script pour analyser ce dont vous avez besoin. Sinon, je peux essayer d'écrire un script ici, mais il pourrait y avoir des allers-retours pour le faire fonctionner de cette façon.

Salut @JohnMcLear , le script est enfin terminé. Je ne sais pas pourquoi cela a pris si longtemps (près de 40 heures). Quoi qu'il en soit, quand on y regarde, il me semble que tout l'exercice peut être fait en sélectionnant la révision la plus élevée qui est divisible par 100 dans la table de stockage et en en extrayant le texte? À l'avenir, je ferai cela à la main :) Merci beaucoup pour votre aide

Exactement cela, mais je suis souvent averti par nos utilisateurs lorsque je suppose qu'ils peuvent effectuer des requêtes de base de données, alors j'essaye de l'éviter. Je pense que je sais pourquoi cela a pris si longtemps btw, utilisez-vous MySQL @ Etherpad 1.8.3?

J'utilise le dernier master de git (je ne sais pas quelle version c'est)

En supposant que MySQL est un bogue connu, nous devons avoir le correctif aujourd'hui.

oui désolé, sa dernière MariaDB - 10.3.22-MariaDB

@JohnMcLear je

Non mais il suffit d'installer npm [email protected] pour corriger

Btw la nouvelle logique pour stocker un texte supplémentaire est dans donc cela devrait être fermé, mais si les gens rencontrent un problème, veuillez créer un nouveau problème et vous référer à celui-ci. Je veux traiter chaque cause individuelle de problème au cas par cas avec l'objectif principal de créer une logique automatisée pour restaurer un tampon en cas de corruption détectée en temps réel. C'est le rêve car la corruption est inévitable.

Ceci est un message destiné aux personnes qui y parviennent récemment (lors de la mise à niveau à partir d'anciennes versions d'etherpad).

Aujourd'hui, j'ai mis à niveau un service etherpad de 1.6.3 à 1.8.6 (quel changement !!!!! félicitations à tous les développeurs)

J'ai eu des problèmes avec un pad, les contrôleurs (checkPad, checkAllPads, etc.) ne l'ont pas détecté (ou je ne sais pas comment exécuter le nœud correctement, de toute façon).

J'ai vérifié que charset est utf8mb4 dans mon settings.json (vu la dernière version dans settings.json.template ).

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

pour le cas https://pad.example.com/p/my-broken-pad j'ai fait:

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

et cela a fonctionné à nouveau: tada:: licorne:: sparkles:

cette solution était au dessus (j'ai mis un +1 sur les messages précédents avec la solution pour aider à la trouver), mais je voulais qu'elle soit plus claire

Je suppose qu'une chose que nous pourrions faire ici est de vérifier ???? dans le contenu de la tablette et fournissez un avertissement qui inclut une solution suggérée @ pedro-nonfree s'il vous plaît pourriez-vous soumettre un correctif à checkPad.js ou quelque chose, alors je serais heureux de le fusionner :)