Etherpad-lite: Error no detectado: afirmación fallida: conjunto de cambios no válido (error checkRep)

Pruebe la última rama de desarrollo y avísenos si todavía ocurre

Esto no es trivial ya que ocurre por casualidad en el servidor prod con muchos usuarios y no puedo reproducirlo.
Solo puedo probar si las almohadillas rotas permanecen rotas en el desarrollo, si eso ayuda.

sí por favor

Conseguiré copiar la base de datos en dev la próxima semana. Informaré lo antes posible. Gracias por su pronta respuesta.

Desafortunadamente, moverse para desarrollar no ha reparado las almohadillas dañadas. Curiosamente, los servidores en movimiento (simple exportación / importación de sql) han "reparado" uno de los pads. Funciona en el nuevo servidor (incluso en 1.3.0), pero otros pads de daños no. Sigue siendo el mismo error.

Este es un error realmente extraño y las almohadillas a veces parecen simplemente "autorepararse" incluso en PROD y sin ningún cambio de nuestra parte.

En teoría, este problema no debería ocurrir en absoluto, ya que los datos incorrectos nunca deberían encontrar su camino ahora ...

Puedo dejar esto abierto y si ocurre con datos nuevos, podemos intentar resolverlo.

¿Qué quiere decir con "datos nuevos"? ¿Tengo que ponerme PROD en desarrollo e intentar conseguir nuevas almohadillas rotas?

Hrm, eso sería potencialmente doloroso ... Tal vez esperar a 1.4, que debería salir en unas pocas semanas como máximo.

Podríamos hacer eso. Muchas gracias.

También tengo ese problema, con la misma extraña aleatoriedad. Actualicé a etherpad-lite 1.4 y todavía está allí. URL de uno de los pads http://etherpad.usabilidoido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4

Ahora mismo estoy en el proceso de actualizar a 1.4 y espero poner en marcha la nueva versión, para poder comprobar si surgen nuevos defectos en los pads nuevos después de ejecutar la nueva versión.

@usabilidoido puede decirle a sus usuarios que exporten-importen el pad. Puede acceder a los controles agregando / timeslider a la url de esta manera: http://etherpad.usabilidoido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4 / timeslider

Exportar como html y luego importar a un nuevo pad.

Estoy experimentando este problema en 1.4. En pads rotos, la línea de comando muestra [WARN] client - Uncaught TypeError: Cannot read property 'length' of undefined cuando el navegador muestra el error Failed assertion .

Sugerencia de sombrero a @ Ra1d3n para la solución alternativa / timeslider. Me alegra ver que el contenido de la plataforma todavía está accesible allí.

Esto es solo una corazonada, pero si lo desea, pruebe con la rama experimental try/client-init-remove-checkRep que acabo de crear. (Esto es generalmente algo peligroso de hacer, pero creo que vale la pena intentarlo).

He actualizado todo a 1.4. y ayer volvimos a tener una almohadilla rota. Podría ser uno que se rompió antes de la actualización, pero no estoy seguro. Seguiré buscando.

@marcelklehr Desafortunadamente, no puedo mover el servidor de producción a una versión _dangerous_. Y no puedo reflejar solicitudes en un servidor secundario porque no tengo los recursos. : - /

Lo siento, no estaba claro: no ejecute try/client-init-remove-checkRep en producción, pero intente acceder a las almohadillas rotas con etherpad ejecutándose en esa rama.

Eliminé checkRep en esa rama, porque sospecho que la normalización puede no funcionar correctamente en algunos casos. Entonces, cuando una almohadilla rota funciona en esa rama sin ningún problema, tenemos que revisar este método.

@marcelklehr Acabo de hacerlo, y desafortunadamente no ayudó.

Proceso:

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

Confirmé que el cambio está realmente en el sistema de archivos. (el comentario y la nueva línea están ahí) El error sigue siendo el mismo.

Recibí el error que mencionó @ericpedia , y no ocurrió en otros pads que no sean el dañado.

consola en el servidor:

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

Cuando mato el servidor, el mensaje se muestra en el cliente, también:

Es posible que pueda darle una importación SQL de la plataforma rota, pero primero deberá decirme qué es exactamente lo que necesita extraer de la base de datos. :-)

El contenido real del pad sería muy útil, por lo que sería la tecla db pad:<PADID> (http://etherpad.org/doc/v1.4.0/#index_pad_padid) y quizás algunas de las últimas revisiones.

Creo que me estoy acercando:

checkPad dice:

$ 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

La aplicación no coincidente en todos los casos significa que el conjunto de cambios en cuestión esperaba un carácter menos que el presente (es decir, un carácter inesperado). Después de examinar el volcado de db, descubrí que todos estos conjuntos de cambios siguen una revisión con un texto adjunto (no todas las revisiones incluyen el contenido completo del pad, sino solo el delta, sin embargo, de vez en cuando por razones de rendimiento, el contenido completo están adjuntos).

Es de suponer que algo salió mal con esta metapropiedad al almacenar la revisión o al crear el texto actual para un nuevo cliente de pad.

Acabo de reescribir checkPad para usar el texto calculado en lugar del almacenado en caché y el pad pasa. ¡Incluso los atextos en caché son correctos! ¡Esto me hace pensar que hay un error en algún algoritmo que calcula el texto completo para client_vars!

Buen trabajo hasta ahora Marcel. Parece que estás cerca de resolver esto.

Ah, no es el generador client_vars. El algoritmo responsable de crear el texto en caché está roto.

@ Ra1d3n Como solución rápida, puede revivir sus pads rotos eliminando la propiedad de metatexto de todas las revisiones clave (donde revNo % 100 == 0 ). "Volver a insertar" todos los registros relacionados con una almohadilla rota se informó como una solución para problemas similares hace mucho tiempo; ahora sabemos por qué funciona :)

@marcelklehr ¿

He realizado algunos cambios en el script checkPad. Vea aquí: # 1653
Pero esto es más un truco sucio. Si mi script resuelve este problema, escribiré un script para arreglar pads

Genial, lo espero con ansias. En este momento, solo tenemos una almohadilla rota por semana, por lo que me inclino a esperar una solución adecuada. :-) Gracias.

Sí, estaba pensando en un guión.

Entonces, la diferencia entre el texto calculado y el en caché muestra que: "концертов" de alguna manera se convirtió en "ко цертов". En otra revisión, "з" también se convirtió en " " ...

No estoy seguro de qué se trata. Estos caracteres están en el BMP Unicode, afaik, así que no sé qué les pasó.

Las mutaciones en la almohadilla de @ Ra1d3n ocurren en las revisiones clave 4900, 11400, 12300 y 13600 (cada 100 revoluciones es una rev clave, lo que significa que almacenará en caché el contenido completo de la almohadilla). Además, el AttributedText almacenado en el registro del pad también está dañado. Todas las demás revisiones clave están bien. (analizado con este guión )

Los caracteres parecen extrañamente aleatorios. En realidad, nada sobresale. No veo un patrón.

Sospecho que algo va mal al almacenar AttributedText en la base de datos. Dado que a veces el pad se recupera entre revisiones de teclas rotas, supongo que el texto almacenado en la memoria es bueno. A veces, cuando se almacena en la base de datos, de alguna manera se corrompe. Si los autores continúan editando el documento hasta que se crea la siguiente revisión clave y esa revisión no termina corrompiéndose, nadie notará nada.
Sin embargo, si el servidor se apaga _antes_ de lograr guardar exitosamente el AText válido en la memoria en la base de datos, el pad se romperá en el próximo inicio del servidor.

@marcelklehr Tuvimos un fallo de etherpad y nos recuperamos varias veces debido a un complemento que no estaba bien codificado, ¿podría ser esta la causa? Es extraño que sea solo una letra que se corrompe cada vez.

Creé un script para reinsertar todo el valor de la base de datos de un pad. En mis pads rotos, el guión no ha funcionado.
@ Ra1d3n Puede descargar el script aquí: https://github.com/Gared/etherpad-lite/blob/pad-repair-script/bin/repairPad.js
Asegúrese de que su instancia de etherpad no se esté ejecutando mientras ejecuta este script.

@Gared ¿ sacas los valores en tu script? Recomiendo trabajar con mi bifurcación checkPad, ajustándola para insertar los valores de AttributedText recalculados en la base de datos.

Es poco probable que los bloqueos de @ Ra1d3n Etherpad causen corrupción de datos, diría yo.

@marcelklehr Probablemente solo hizo que el problema fuera más visible, porque en esos casos perdimos el valor de memoria correcto.

@marcelklehr Este script es una bifurcación del script extractPadData. Los valores y las claves se cargan en la función anterior. Estas son todas las teclas de un pad.

El script repairPad.js de @Gared está arreglando mis pads rotos. ¿Alguna posibilidad de que esta solución se incorpore en la próxima versión de etherpad-lite?

Claro, solo envíe una solicitud de extracción con él o pídale a @Gared que

Solicitud de extracción abierta # 2210

Mi etherpad se está ejecutando en 1.4.1 y tengo 3 veces el mismo problema descrito anteriormente: el pad no se puede cargar pero / timeslider funciona bien.
2 de ellos ahora se están repitiendo sin hacer nada.
En el tercer pad, probé sin éxito el repairPad.js. Su url es: +1: http://portail.univ-lille1.fr/etherpad/link.jsp?groupID=g.jfobkKVrkydeTwLY&padID=SES_Grp8_Macroeconomie (debe hacer clic en "utilisez le pad avec l'invitexy" para acceder a el pad mismo.

¿Quizás hay un conjunto de cambios con un valor normal que no es tomado en cuenta por repairPad o hay alguna nueva versión de reparPad.js que no he visto en git?

Creemos que tenemos una solución para esto ahora. Por favor, tire de desarrollar y probar :) ¡Gracias!

Hola, nos acaba de ocurrir esto. Ejecutamos 1.5.7, que es la última versión publicada. Backend es una base de datos MySQL. No tengo indicaciones sobre las acciones del usuario que puedan haber causado esto.

Pad en cuestión: https://etherpad.wikimedia.org/p/iOS-iteration-planning

Obtener los datos de la almohadilla a través del truco del calendario funciona bien. Sin embargo, la almohadilla nunca se cargará.

Cualquier cosa en la base de datos se puede volcar y proporcionar para depuración si ayuda.

hola, tuve esta discusión en la mañana.
08:47 <webzwo0i> mutante: depuré el pad. normalmente no debería hacer esto, pero si tiene una copia de seguridad de la base de datos (y después de hacer una exportación / etherpad para tener una copia de seguridad de
el pad) puede cambiar tres entradas de la base de datos y el pad debería estar funcionando bien nuevamente. los tres comandos de mysql son

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> ¿puede comprobar si su base de datos está ejecutando utf8mb4 charset o utf8?
08:51 <webzwo0i> oha ups, no apliques los comandos mysql. tal vez fui un poco demasiado rápido :-) necesito verificar algo primero
09:08 <webzwo0i> mh no, debería estar bien, por favor pruebe ... sería bueno saber si ejecutó la última versión o algo más y qué complementos ha habilitado
09:47 <webzwo0i> No sé si ustedes en wikimedia se conocen, pero si pueden averiguar quién es el usuario "Brian", ¿podrían preguntarle qué navegador está usando? la
la razón es que puedo ver cuál es el error, pero no puedo activarlo en mi navegador (solo manualmente, pero debido a que ustedes no son hostiles, probablemente no estaba en
propósito)
09:49 <webzwo0i> (por lo que probablemente tengamos dos errores, uno del lado del servidor y otro del lado del cliente)

la información que necesito es si su base de datos es utf8 o utf8mb4
He extraído el conjunto de cambios ofensivo, el calendario temporal no funcionará con estas revisiones si no las aplica también

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

junto con las actualizaciones de arriba, esto debería hacer que su almohadilla sea reutilizable nuevamente

@ webzwo0i

Sí, noté que el mutante habló contigo. También decidí hacer un seguimiento del problema de github. Buscaré quién es "Brian" y qué navegador está usando para ti.

Entonces, la tabla de la tienda es utf8mb4 desde hace bastante tiempo. Era utf8 pero lo convertimos a utf8mb4 debido a un conjunto diferente de problemas en junio. Específicamente el 23 de junio de 2015

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

no es necesario averiguar el usuario / navegador, puedo reproducir el error ahora. ¡gracias!

Debido a que está en la última versión, debe insertar "charset": "utf8mb4" en settings.json dentro de dbSettings. Esto ahora está en settings.json.template. Puede comprobar si esto es necesario con

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

el cliente (¿y tal vez la conexión?) debe indicar utf8mb4, si no las tablas de su base de datos son capaces de almacenar 4 bytes utf8 pero el servidor no espera 4byte utf8 ni la conexión del cliente.
Esto no repara sus almohadillas viejas. Sin embargo, puede iterar sobre todos sus pads y usar bin / checkPad.js para tener una idea de cuántos y qué pads pueden tener problemas similares. Dependiendo de las circunstancias puede ser muy fácil de reparar (aunque algunos personajes se romperán) como en el caso anterior. Si hay muchas almohadillas rotas, podría tener sentido automatizar esto.

La razón por la que estos problemas no se ven cuando la gente está escribiendo es que la mayoría de los sitios utilizan el caché interno de ueberDB para mejorar el rendimiento. Esta caché de JavaScript puro es totalmente consciente de Unicode. Tan pronto como se vacíe la caché o se reinicie etherpad, es necesario obtener las entradas de la base de datos.

He reparado la almohadilla como me indicó. Es interesante descubrir que 4 signos de interrogación seguidos dañarían un PAD de esa manera. Y que el conjunto de cambios corruptor sería tan antiguo en comparación con la punta del pad. Pero tu explicación tiene sentido, gracias por eso.

También he actualizado la configuración con "charset": "utf8mb4".

Estoy siguiendo el ticket de phabricator en wikimedia pero no tengo una cuenta allí, así que lo publico aquí.

Su segunda almohadilla rota también se puede reparar usando:

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

Los 4 signos de interrogación son el síntoma porque, iirc, los bytes individuales en UTF8 de cuatro bytes no son UTF8 válidos. (En UTF8, solo los primeros 127 caracteres se representan como bytes individuales, UTF8 multibyte probablemente usa bytes por encima de 0x7f). Entonces, 4 signos de interrogación en realidad representan una cadena UTF8 codificada de 4 bytes, que representa un punto de código fuera del plano multilingüe básico (lo más probable es que un emoji :-D). En Javascript, esos puntos de código se codificarían utilizando los pares sustitutos de UTF16, que son 2 valores de 16 bits.

El problema de checkRep es que en los conjuntos de cambios no solo almacenamos los caracteres, sino también la longitud del cambio. La función length () de Javascript, sin embargo, cuenta los pares sustitutos como 2, por lo que, por ejemplo, un emoji tiene una longitud de 2. Cuando mysql decodifica la cadena de un conjunto de cambios en signos de interrogación, nuestra representación de un conjunto de cambios ya no es válida.

Reemplazarlo con dos signos de interrogación es un truco, no una solución real porque no tenemos idea de qué punto de código ingresó el usuario en primer lugar (pero mientras el valor esté en la caché de ueberDB, podríamos sacarlo de allí).

produciría resultados incorrectos si alguien realmente usa cuatro signos de interrogación (nuestro valor de longitud indicaría 4, si lo reemplazamos con 2 signos de interrogación obtendríamos un error checkRep a cambio) por lo que si automatizamos un script de reparación tendríamos que verificar si la longitud de la cadena después de aplicar nuestro cambio se ajusta al valor "cuántos caracteres se agregan" del conjunto de cambios.

Para solucionar el problema si alguien realmente usó cuatro signos de interrogación y además puntos de código como emoji, también necesitamos rastrear la posición dentro del documento donde reemplazamos los signos de interrogación.

También tenga en cuenta que no todos los errores checkRep son causados ​​por una codificación rota

Y, por supuesto, lo anterior funcionó. ¡INCREÍBLE! No puedo agradecerte lo suficiente. Espero que con la corrección de la configuración en su lugar, esto no vuelva a suceder.

Me preguntaba si la depuración que está haciendo es manualmente por cierto. Obtener y comparar los conjuntos de cambios y sus longitudes uno por uno manualmente o si tiene alguna forma más automatizada de hacerlo. Supongo que puedo crear uno propio de todos modos, solo por curiosidad

<3 @ webzwo0i Gracias hombre, eres increíble

@ webzwo0i He estado haciendo una buena cantidad con obtener el representante de caracteres de una coordinación X en un elemento últimamente (para arrastrar y soltar) y tengo la sensación de que voy a encontrar este problema en el que ciertos personajes están mal envueltos . Será interesante probar que en algún momento

El error se puede reproducir fácilmente creando una nueva almohadilla con un solo emoji (por ejemplo, 🐼) y reiniciando etherpad, ver también # 3340.

Actualización : a partir de abril de 2019, este solo emoji en sí mismo no rompe una almohadilla, incluso después de reiniciar.

Quería revisar todas las almohadillas, así que agregué una herramienta checkAllPads (ver PR # 3342).

El error se puede reproducir fácilmente creando una nueva almohadilla con un solo emoji (por ejemplo, panda_face) y reiniciando etherpad, ver también # 3340.

No puedo reproducir esto, haciendo exactamente lo que se describió anteriormente. Consulte https://etherpad.wikimedia.org/p/ohmy para ver un ejemplo (sí, ya reinicié etherpad varias veces)

También tuvimos una rotura de almohadilla con este error. Curiosamente, checkPad,js no encuentra ningún problema y repairPad.js se completa sin solucionarlo. ¿Hay alguna forma de determinar qué revisión tiene la culpa?

EDITAR: Ah, encontré https://gist.github.com/marcelklehr/a78d293571e7f06e3cf9 que me indicó el camino correcto. ¿Alguna posibilidad de que esto pueda incluirse en el propio etherpad? Ha sido infinitamente útil en este momento, ¡muchas gracias! (Sin embargo, tuve que reemplazar console.log por console.error para incluso ver los números de revisión. No tengo experiencia en nodeJS, pero no pude encontrar otra forma de ver realmente todo el registro. )

De hecho, hacer el "reemplazar ???? por ?? " también ayudó aquí. :) Parece que el último conjunto de cambios fue alguien insertando un emoji (terminó en $???? ).

Sin embargo, no entiendo por qué esto se clasifica como un "error menor". Este error conduce a la pérdida total de una libreta (hasta que alguien se da cuenta de la cosa /timeslider , que en nuestro caso tomó una semana, e incluso entonces se pierde el historial).

Yo mismo no asignado, ya que es poco probable que pueda arreglar esto. FWIW, este error parece deberse a una limitación de la biblioteca easysync, que estoy especulando que no es compatible con todos los utf-8. (UTF-8 puede codificar un carácter como varios bytes, cada uno de los cuales se suma a la longitud de una cadena en javascript, aunque sea solo un carácter).

-- Olvídalo

FWIW, este error parece deberse a una limitación de la biblioteca easysync, que estoy especulando que no es compatible con todos los utf-8. (UTF-8 puede codificar un carácter como varios bytes, cada uno de los cuales se suma a la longitud de una cadena en javascript, aunque sea solo un carácter).

En realidad, tenemos diéresis (äöü) en nuestros pads todo el tiempo, que también son multibyte en UTF-8. Basado en lo que se ha dicho anteriormente, creo que el problema es en realidad sobre UTF-16, que, cuando se diseñó originalmente, tenía la intención de tener exactamente 2 bytes por carácter (punto de código, en realidad), pero ahora que tenemos más de 2 ^ 16 puntos de código, hay algunos que necesitan 4 bytes, como emojis. Y ahora length() ya no coincide con el número de puntos de código y todo se confunde.

Entonces, ¿quizás una mejor solución es rechazar por completo cualquier par sustituto (puntos de código de 4 bytes)? Eso haría imposible usar etherpad con personajes del plano suplementario , pero parece que de todos modos está roto. Y debería proteger la base de datos. Parece haber formas de probar pares sustitutos en JS (pero no tengo experiencia en JavaScript moderno).

¿Por qué se cerró esto? Que yo sepa, Etherpad todavía se atraganta con personajes fuera del BMP. Recientemente, nuevamente tuve que reparar manualmente una almohadilla que se rompió de esta manera.

Lo cerré porque abrí el Issue 2014 y ya no estaba interesado en él.

Bueno, todavía es un problema abierto para otros, así que le agradecería si pudiera reabrir.

¡Gracias! :)

¿Alguien tiene algún ejemplo de un carácter (secuencia) que rompe un pad de manera confiable? Supongo que esto facilitaría la depuración.

La biblioteca Easysync describe el texto (y su extensión) en términos de "caracteres", pero era un producto mínimo viable desde hace 10 años. Hoy en día probablemente deberíamos pensar en términos de puntos de código UTF-8 normalizados por NFC.

Me pregunto si podríamos resolver el problema almacenando los valores de ueberdb como blobs binarios en lugar de en una columna de texto intercalado.

Actualmente, si intentamos poner una secuencia de bytes que no es válida utf8mb4 (piense: un conjunto de cambios que contiene parte de un carácter multibyte) en una columna utf8mb4 , solo hay dos resultados posibles: o la base de datos rechaza el entrada, o el cliente (o servidor) necesita eliminar (piense: reemplazar con "?") los "caracteres" o bytes no válidos antes.

Al usar una columna de blob binaria, a la base de datos ya no le importaría que la secuencia de bytes sea utf8mb4 no válida, por lo que podríamos evitar el reemplazo de caracteres. Si easysync es tan independiente de la codificación como tengo entendido, esto podría funcionar (siempre que dos usuarios no inserten caracteres multibyte AB y CD en la misma posición al mismo tiempo y estos terminen como conjunto de cambios individuales A, C, B, D - en este order -, lo que hace que el resultado combinado no sea válido (utf8mb4).

PD: Acabo de probar que insertar un carácter UTF8 de 4 bytes como 🍰 no es un problema en sí mismo (aunque: no reinicié todavía, lo que puede ser una explicación), así que supongo que el error requiere concurrencia (lo que lleva a que el carácter sea dividido en dos o más conjuntos de cambios que no son válidos por sí mismos) o requiere que un cliente emita un conjunto de cambios que elimine parte de dicho carácter.

Hola, también estamos experimentando este problema en muchos pads.

Estoy intentando todo y no puedo reemplazar esto con 🍰, intenté reiniciar, diferentes backends de base de datos (que están configurados correctamente).

¿Alguien puede proporcionar pasos para replicar con nuestra base de código más moderna?

Presionar la tecla de retroceso en 🍰 reemplaza el elemento con , lo que obviamente es una mierda.

Para mí, replace( valor ,'????','??') siempre ha funcionado hasta ahora. Sin embargo, no ha sucedido durante unos meses.

Incluí una versión actualizada de Check Pad Deltas que funciona, si la gente puede intentarlo para ver si ayuda cuando experimenta este problema, lo agradecería.

Sigo pensando que el problema básico es que el modelo de datos Etherpad piensa en términos de "caracteres" y no de puntos de código UTF-8 normalizados.

A menos que modifiquemos la biblioteca principal, esto nunca se resolverá realmente. Obviamente, cualquier mitigación es útil. Solo digo que no hay soluciones _fáciles_ que estén garantizadas al 100% en mi opinión.

Te sorprendería saber cuántos editores (y muy populares entre los desarrolladores) tienen una experiencia similar a Etherpad aunque. Jugando hoy tuve algunas experiencias locas.

Incluí una versión actualizada de Check Pad Deltas que funciona, si la gente puede intentarlo para ver si ayuda cuando experimenta este problema, lo agradecería.

Se detuvo en la rama principal con # 3717 (14ae2ee95094).

Hola, tenemos un problema similar con uno de nuestros pads.
@JohnMcLear desafortunadamente la última versión de checkPadDeltas no ayudó: /

@gnd ¿tienes una instancia pública?

¿Puede presionar la URL padId / export / etherpad y obtener el archivo .etherpad?

¿Está ejecutando el último desarrollo?

¿Cuál es el backend de su base de datos?

Tantas preguntas, proporcione tantos detalles como sea posible

@JohnMcLear
Sí, es una instancia pública: https://pad.xpub.nl/p/CareCircle
Desafortunadamente, aparece un error 502 Bad Gateway al intentar obtener el archivo .etherpad
Estamos ejecutando el último desarrollo (git pull origin) en nodejs 12.16.3-1nodesource1, con el backend de db como 10.3.22-MariaDB-0 + deb10u1.

Estoy disponible hoy para ayudarlo con cualquier tipo de depuración que desee hacer. Ya probé la última versión de checkPadDeltas, sin embargo, se bloquea durante horas después del inicio. Esta es la única salida que da:

Todas las rutas relativas se interpretarán en relación con el directorio base Etherpad identificado: / opt / etherpad
[2020-05-05 00: 04: 12.330] [DEBUG] AbsolutePaths - La ruta relativa "settings.json" se puede reescribir a "/opt/etherpad/settings.json"
[2020-05-05 00: 04: 12.346] [DEBUG] AbsolutePaths: la ruta relativa "credentials.json" se puede reescribir en "/opt/etherpad/credentials.json"
configuración cargada desde: /opt/etherpad/settings.json
No se encontró ningún archivo de credenciales en /opt/etherpad/credentials.json. Postergación.
[2020-05-05 00: 04: 12.369] Consola [INFO] - Uso de skin "sin skin" en el directorio: / opt / etherpad / src / static / skins / no-skin
[2020-05-05 00: 04: 12.371] Consola [INFO] - Clave de sesión cargada desde: /opt/etherpad/SESSIONKEY.txt
[2020-05-05 00: 04: 12.541] Consola [ERROR] - la tabla no está configurada con charset utf8 - Esto puede provocar bloqueos cuando se pegan ciertos caracteres en los pads
[2020-05-05 00: 04: 12.543] Consola [INFO] - RowDataPacket {character_set_name: 'utf8mb4'} utf8

¡Amigo, el error está en tu registro!

[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

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

@JohnMcLear
nuestro db tiene

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

Mientras que la mesa de la tienda tiene

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

Entonces debería convertir usando
ALTER DATABASE etherpad_lite_db CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

?

@JohnMcLear

La mala configuración fue doble, la base de datos estaba usando utf8 y utf8_general_ci, pero también en settings.json el juego de caracteres para la base de datos se estableció como "utf8". Habiendo arreglado todo eso en utf8mb4 todavía no ayudó, y el pad en cuestión no se carga, y checkPadDeltas todavía se cuelga:

Todas las rutas relativas se interpretarán en relación con el directorio base Etherpad identificado: / opt / etherpad
[2020-05-05 13: 17: 43.443] [DEBUG] AbsolutePaths - La ruta relativa "settings.json" se puede reescribir a "/opt/etherpad/settings.json"
[2020-05-05 13: 17: 43.444] [DEBUG] AbsolutePaths: la ruta relativa "credentials.json" se puede reescribir en "/opt/etherpad/credentials.json"
configuración cargada desde: /opt/etherpad/settings.json
No se encontró ningún archivo de credenciales en /opt/etherpad/credentials.json. Postergación.
[2020-05-05 13: 17: 43.463] Consola [INFO] - Uso de skin "sin skin" en dir: / opt / etherpad / src / static / skins / no-skin
[2020-05-05 13: 17: 43.464] Consola [INFO] - Clave de sesión cargada desde: /opt/etherpad/SESSIONKEY.txt

@gnd Es un problema de GiGo. Una vez que tiene basura, no se puede cambiar. ¡Ahora todo lo que sabes es que el problema no aparecerá en el futuro!

@gnd Es un problema de GiGo. Una vez que tiene basura, no se puede cambiar. ¡Ahora todo lo que sabes es que el problema no aparecerá en el futuro!

¿No podría repairPad.js reparar estas almohadillas rotas?

Oh, hola @caugner , lamentablemente no, repairPad.js generalmente apesta y realmente no funciona. https://github.com/ether/etherpad-lite/blob/develop/bin/repairPad.js#L48

Lo mejor que puedo sugerir es sacar el texto / texto de la libreta y llevarlo a una nueva libreta.

@gnd ¿ Puedo escribirle un script para probar y tratar de obtener el texto si lo desea?

bin/extractPadData.js con un cambio en la salida a stdout podría ser suficiente aquí .. 2mins crearé un extractPadText.js

@JohnMcLear eso sería muy útil de hecho)

Extrayendo

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

El texto es el elemento val.atext.text , puede analizarlo json en cli .. Lo haré a continuación si lo necesita .. Por ahora, haga estos comandos asegurándose de reemplazar $ padid con su PadID

Analizando

sudo apt-get install jq para instalar jq y luego cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text para ver solo el texto.

Para escribir el texto del Pad en un archivo de texto cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text > $padid.txt

Ahora que tiene el texto del pad, puede ponerlo en un archivo de texto e importarlo o configurar la API de texto o lo que sea ...

Déjame saber si la extracción falla y consideraré otro enfoque.

La extracción se está ejecutando, sin embargo, es bastante lenta. En el archivo CareCicle.db veo la última línea en revs: 80 , mientras que el script ya se ejecuta durante 20 m. El bloc de preguntas tiene más de 12k revisiones.

Oh, hombre, eso apesta ... Supongo que no se puede construir el objeto pad después de 80 revisiones ... La secuencia de comandos solo debería tardar unos 30 segundos en ejecutarse.

la última sugerencia sería grande, volcar la base de datos completa y enviármela y luego puedo escribir un script para analizar lo que necesita. Alternativamente, puedo intentar escribir un guión aquí, pero puede haber algunos intercambios para que funcione de esa manera.

Hola @JohnMcLear , el guión finalmente ha terminado. No tengo idea de por qué tardó tanto (casi 40 horas). De todos modos, al mirarlo, me parece que todo el ejercicio se puede hacer seleccionando la revisión más alta que es divisible por 100 de la tabla de la tienda y extrayendo el texto de ella. En el futuro haré esto a mano :) Muchas gracias por tu ayuda

Exactamente esto, pero a menudo nuestros usuarios me regañan cuando supongo que pueden realizar consultas en la base de datos, así que trato de evitarlo. Creo que sé por qué tomó tanto tiempo por cierto, ¿estás usando MySQL @ Etherpad 1.8.3?

Estoy usando el último maestro de git (no estoy seguro de qué versión es)

Suponiendo que MySQL es un error conocido, el parche debería aterrizar hoy.

sí, lo siento, su última MariaDB - 10.3.22-MariaDB

@JohnMcLear lamento

No, pero simplemente instale npm [email protected] para solucionarlo

Por cierto, la nueva lógica para almacenar texto adicional está en, así que esto debería cerrarse, pero si las personas experimentan un problema, cree un nuevo problema y consulte este. Quiero tratar cada causa individual del problema, caso por caso, con el objetivo principal de crear una lógica automatizada para restaurar una plataforma cuando se detecte una corrupción en tiempo real. Ese es el sueño, ya que la corrupción es inevitable.

Este es un mensaje para las personas que están recibiendo esto recientemente (al actualizar desde versiones anteriores de etherpad).

Hoy actualicé un servicio de etherpad de 1.6.3 a 1.8.6 (¡¡¡Qué cambio !!!!! Felicitaciones a todos los desarrolladores)

Tuve problemas con un pad, las fichas (checkPad, checkAllPads, etc.) no lo detectaron (o no sé cómo ejecutar el nodo correctamente, de todos modos).

Verifiqué que charset es utf8mb4 en mi settings.json (vi la última versión en settings.json.template ).

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

para el caso https://pad.example.com/p/my-broken-pad que hice:

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

y funcionó de nuevo: tada:: unicornio:: brilla:

esta solución estaba arriba (puse un +1 en mensajes anteriores con la solución para ayudar a encontrarla), pero quería tenerlo más claro

Supongo que una cosa que podríamos hacer aquí es buscar ???? en el contenido de la almohadilla y proporcionar una advertencia que incluya una solución sugerida. @ pedro-nonfree, por favor, ¿podría enviar un parche a checkPad.js o algo? Entonces felizmente lo fusionaría :)