Etherpad-lite: Erro não detectado: declaração falhada: conjunto de alterações inválido (falha em checkRep)

Experimente o branch Develop mais recente e diga-nos se ainda ocorre

Isso não é trivial, pois ocorre por acaso no servidor prod com muitos usuários e não consigo reproduzi-lo.
Só posso testar se as almofadas quebradas continuam quebradas no desenvolvimento, se isso ajudar.

sim por favor

Vou copiar o banco de dados para o dev na próxima semana. Apresentarei um relatório o mais rápido possível. Obrigado pela resposta rápida.

Infelizmente, a mudança para o desenvolvimento não reparou as almofadas danificadas. Curiosamente, a movimentação de servidores (exportação / importação simples de sql) "consertou" um dos pads. Ele funciona no novo servidor (mesmo no 1.3.0), mas outros pads de danos não. Continua o mesmo erro.

Este é um bug realmente estranho e as almofadas às vezes parecem apenas "autorreparar" mesmo no PROD e sem nenhuma mudança de nossa parte.

Em teoria, esse problema não deveria ocorrer, pois os dados ruins nunca deveriam ser encontrados agora.

Posso deixar isso em aberto e se ocorrer em novos dados, podemos tentar resolvê-lo.

O que você quer dizer com "dados novos"? Preciso desenvolver o PROD e tentar obter novas almofadas quebradas?

Hrm, isso seria potencialmente doloroso .. Talvez esperar por 1,4, que deve sair em algumas semanas no máximo

Podemos fazer isso. Muito obrigado.

Eu também tenho esse problema, com a mesma estranha aleatoriedade. Eu atualizei para o etherpad-lite 1.4 e ele ainda está lá. URL para um dos pads http://etherpad.usabilidoido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4

Estou agora no processo de atualização para 1.4 e espero que vá ao ar com a nova versão, para que eu possa verificar se novos defeitos surgem em novos blocos depois de executar a nova versão.

@usabilidoido você pode dizer aos seus usuários para exportar-importar o pad. Você pode acessar os controles adicionando / timeslider ao url desta forma: http://etherpad.usabilidoido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4 / timeslider

Exporte como html e depois importe para um novo pad.

Estou tendo esse problema em 1.4. Em pads quebrados, a linha de comando mostra [WARN] client - Uncaught TypeError: Cannot read property 'length' of undefined quando o navegador mostra o erro Failed assertion .

Gorjeta de chapéu para @ Ra1d3n para a solução alternativa / timeslider. Fico feliz em ver que o conteúdo do pad ainda está acessível lá.

Este é apenas um palpite, mas se quiser, tente com o branch experimental try/client-init-remove-checkRep que acabei de criar. (Isso geralmente é uma coisa perigosa de se fazer, mas vale a pena tentar, eu acho.)

Eu atualizei tudo para 1.4. e ontem tivemos uma almofada quebrada novamente. Ainda pode ser um que quebrou antes da atualização, mas não tenho certeza. Eu vou continuar procurando.

@marcelklehr Infelizmente, não consigo mover o servidor de produção para uma versão _dangerous_. E não posso espelhar solicitações para um servidor secundário porque não tenho os recursos. : - /

Desculpe, não estava claro: não execute try/client-init-remove-checkRep na produção, mas tente acessar os pads quebrados com o etherpad em execução naquele branch.

Removi checkRep daquele branch, porque suspeito que a normalização pode não funcionar corretamente em alguns casos. Então, quando um pad quebrado funciona naquele branch sem nenhum problema, temos que revisitar este método.

@marcelklehr Acabei de fazer e, infelizmente, não ajudou.

Processo:

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

Confirmei que a mudança está realmente no sistema de arquivos. (comentário e nova linha estão lá) O erro ainda é o mesmo.

Eu recebi o erro que a @ericpedia mencionou e não ocorreu em outros blocos além do corrompido.

console no 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' }

Quando mato o servidor, a mensagem é exibida no cliente, também:

Eu posso fornecer a você uma importação SQL do pad quebrado, mas você precisa me dizer o que exatamente você precisa extrair do banco de dados primeiro. :-)

O conteúdo real do pad seria muito útil, então seria a chave db pad:<PADID> (http://etherpad.org/doc/v1.4.0/#index_pad_padid) e talvez algumas das últimas revisões.

Acho que estou chegando perto:

checkPad diz:

$ 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

A aplicação incompatível em todos os casos significa que o conjunto de alterações em questão esperava um caractere a menos do que o realmente presente (portanto, um caractere inesperado). Depois de examinar o db dump, descobri que todos esses changesets seguem uma revisão com um atexto anexado (nem todas as revisões incluem o conteúdo completo do pad, mas apenas o delta, no entanto, de vez em quando por motivos de desempenho o conteúdo completo estão inclusos).

Presumivelmente, algo deu errado com essa meta propriedade ao armazenar a revisão ou ao criar o atext atual para um novo cliente de pad.

Acabei de reescrever o CheckPad para usar o atext calculado em vez do armazenado em cache e o pad passa. Até mesmo os textos em cache estão corretos! Isso me faz pensar que há um bug em algum algoritmo que calcula o atext completo para client_vars!

Bom trabalho até agora, Marcel. Parece que você está perto de resolver isso.

Ah, não é o gerador client_vars. O algoritmo responsável por criar o atext em cache está quebrado.

@ Ra1d3n Como uma correção rápida, você pode reviver seus pads quebrados excluindo a propriedade meta atext de todas as revisões principais (onde revNo % 100 == 0 ). "Reinserir" todos os registros relacionados a um pad quebrado foi relatado como uma solução para problemas semelhantes há muito tempo - agora sabemos por que funciona :)

@marcelklehr Isso fará com que o EP reconstrua o pad da revisão 0 no carregamento? Acho que não devo sair por aí excluindo todas as propriedades de texto de todas as revisões então ... :-) Alguma esperança de um script "regenerate Pad" que reconstrói as revisões-chave com um algoritmo correto?

Fiz algumas alterações no script checkPad. Veja aqui: # 1653
Mas este é mais um hack sujo. Se meu script resolver esse problema, vou escrever um script para consertar os pads

Legal, estou ansioso por isso. No momento, temos apenas um bloco quebrado por semana, então estou inclinado a esperar por uma correção adequada. :-) Obrigado.

Sim, eu estava pensando em um roteiro.

Assim, a diferença entre o atext calculado e o armazenado em cache mostra que: "концертов" de alguma forma se transformou em "ко цертов". Em outra revisão, "з" foi transformado em " " também ...

Não tenho certeza do que se trata. Esses chars estão no Unicode BMP, afaik, então não sei o que aconteceu com eles.

As mutações no pad de @ Ra1d3n ocorrem nas revisões principais 4900, 11400, 12300 e 13600 (a cada 100ª rev é uma revisão principal, o que significa que armazenará em cache o conteúdo completo do pad). Além disso, o AttributedText armazenado no registro do pad também está corrompido. Todas as outras revisões importantes estão bem. (analisado com este script )

Os caracteres parecem estranhamente aleatórios. Nada se destaca, realmente. Não vejo um padrão.

Suspeito que algo esteja errado ao armazenar o AttributedText no banco de dados. Como às vezes o pad se recupera entre revisões de teclas quebradas, estou supondo que o texto armazenado na memória é bom. Às vezes, quando é armazenado no banco de dados, ele de alguma forma fica corrompido. Se os autores continuarem a editar o documento até que a próxima revisão principal seja criada e essa revisão não for corrompida, ninguém notará nada.
No entanto, se o servidor for encerrado _antes_ de conseguir salvar com sucesso o AText válido mantido na memória para o banco de dados, o pad será quebrado na próxima inicialização do servidor.

@marcelklehr Ocorreu um travamento e recuperação do etherpad algumas vezes devido a um plugin que não estava bem codificado, poderia ser essa a causa? Estranho que seja apenas uma letra que sempre foi corrompida.

Criei um script para reinserir todos os valores do banco de dados de um pad. Em meus blocos quebrados, o script não funcionou.
@ Ra1d3n Você pode baixar o script aqui: https://github.com/Gared/etherpad-lite/blob/pad-repair-script/bin/repairPad.js
Certifique-se de que sua instância do etherpad não esteja em execução enquanto você executa este script.

@Gared De onde você obtém os valores em seu script? Eu recomendo trabalhar fora da bifurcação do meu checkPad, ajustando-o para inserir os valores de AttributedText recalculados no banco de dados.

@ Ra1d3n Falhas

@marcelklehr Provavelmente apenas tornou o problema mais visível, porque o valor de memória correto foi perdido para nós nesses casos.

@marcelklehr Este script é uma bifurcação do script extractPadData. Os valores e chaves são carregados na função acima. Estas são todas as teclas de um pad.

O script repairPad.js de @Gared está consertando meus pads quebrados. Alguma chance de essa correção ser incorporada na próxima versão etherpad-lite?

Claro, basta enviar uma solicitação pull com ele ou pedir ao @Gared para

Solicitação pull aberta # 2210

Meu etherpad está rodando em 1.4.1 e eu tenho 3 vezes o mesmo problema descrito acima: o pad não consegue carregar, mas / timeslider funciona bem.
2 deles estão sendo executados novamente sem fazer nada.
No terceiro pad, tentei sem sucesso o repairPad.js. Seu url é: +1: http://portail.univ-lille1.fr/etherpad/link.jsp?groupID=g.jfobkKVrkydeTwLY&padID=SES_Grp8_Macroeconomie (você deve clicar em "utilisez le pad avec l'invitexy" para acessar a própria almofada.

Talvez haja um changeset com um valor anormal que não é levado em consideração pelo repairPad ou existe alguma nova versão do reparPad.js que eu não vi no git?

Achamos que temos uma solução para isso agora. Por favor, puxe, desenvolva e teste :) Obrigado!

Olá, acabamos de ver isso acontecer. Rodamos 1.5.7, que é a última versão lançada. Backend é um banco de dados MySQL. Não tenho indicações sobre as ações do usuário que podem ter causado isso.

Pad em questão: https://etherpad.wikimedia.org/p/iOS-iteration-planning

Obter os dados do pad através do truque do timeslider funciona bem. O pad, entretanto, nunca carregará.

Qualquer coisa no banco de dados pode ser despejada e fornecida para depuração se ajudar.

oi, eu tive essa discussão pela manhã.
08:47 <webzwo0i> mutante: depurei o pad. você normalmente não deve fazer isso, mas se você tiver um backup do banco de dados (e depois de fazer o export / etherpad para ter um backup do
o pad) você pode alterar três entradas do banco de dados e o pad deve estar funcionando bem novamente. os três comandos mysql são

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> você pode verificar se seu banco de dados está executando o conjunto de caracteres utf8mb4 ou utf8?
08:51 <webzwo0i> oha ups por favor não aplique os comandos mysql. talvez eu tenha sido um pouco rápido demais :-) preciso verificar algo primeiro
09:08 <webzwo0i> mh nope deve estar bem, por favor, teste ... seria bom saber se você executou a versão mais recente ou outra coisa e quais plug-ins você ativou
09:47 <webzwo0i> Não sei se vocês na wikimedia se conhecem, mas se você puder descobrir quem é o usuário "Brian", você poderia perguntar a ele qual navegador ele está usando? a
a razão é que eu posso ver qual é o bug, mas não consigo ativá-lo no meu navegador (apenas manualmente, mas como seus ppl não são hostis, provavelmente não estava
objetivo)
09:49 <webzwo0i> (então provavelmente temos dois bugs, um do lado do servidor e um do lado do cliente)

a informação de que preciso é se seu banco de dados é utf8 ou utf8mb4
Eu extraí o changeset ofensivo, o timeslider não funcionará em torno dessas revisões se você também não aplicar

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

junto com as atualizações acima, isso deve tornar o seu bloco reutilizável novamente

@ webzwo0i

Sim, percebi que aquele mutante falou com você. Eu apenas decidi acompanhar o problema do github também. Vou rastrear quem é "Brian" e qual navegador eles estão usando para você.

Portanto, a tabela de armazenamento é utf8mb4 há algum tempo. Era utf8, mas convertemos para utf8mb4 devido a um conjunto diferente de problemas em junho. Especificamente em 23 de junho de 2015

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

não há necessidade de descobrir o usuário / navegador, posso reproduzir o bug agora. obrigado!

Como você está na versão mais recente, você precisa inserir "charset": "utf8mb4" em settings.json dentro de dbSettings. Isso agora está em settings.json.template. Você pode verificar se isso é necessário com

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

o cliente (e talvez a conexão?) deve indicar utf8mb4, se não as tabelas do seu banco de dados são capazes de armazenar 4 bytes utf8, mas o servidor não espera 4 bytes utf8 na conexão do cliente.
Isso não repara suas almofadas antigas. No entanto, você pode iterar em todos os seus blocos e usar bin / checkPad.js para ter uma ideia de quantos e quais blocos podem ter problemas semelhantes. Dependendo das circunstâncias, pode ser muito fácil de consertar (embora alguns caracteres estejam quebrados) como no caso acima. Se houver muitos blocos quebrados, pode fazer sentido automatizar isso.

A razão pela qual esses problemas não são vistos quando as pessoas estão realmente escrevendo é que a maioria dos sites usa o cache interno do ueberDB para desempenho. Este cache de puro javascript está totalmente ciente do Unicode. Assim que o cache for liberado ou o etherpad for reiniciado, ele precisará obter as entradas do banco de dados.

Consertei o bloco conforme você instruiu. Interessante descobrir que 4 pontos de interrogação consecutivos corromperiam um PAD dessa forma. E que o changeset corrompido seria tão antigo em comparação com a ponta do pad. Mas sua explicação faz sentido, obrigado por isso.

Eu atualizei a configuração com "charset": "utf8mb4" também.

Estou seguindo o tíquete do phabricator na wikimedia, mas não tenho uma conta lá, então o posto aqui.

Sua segunda almofada quebrada também pode ser reparada 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";

Os 4 pontos de interrogação são o sintoma porque, iirc, os bytes únicos em UTF8 de quatro bytes não são UTF8 válidos. (Em UTF8 apenas os primeiros 127 caracteres são representados como bytes únicos, UTF8 multibyte provavelmente usa bytes acima de 0x7f). Portanto, 4 pontos de interrogação representam, na verdade, uma string UTF8 codificada de 4 bytes, que representa um ponto de código fora do Plano multilíngüe básico (muito provavelmente um emoji :-D). Em Javascript, esses pontos de código seriam codificados usando pares substitutos do UTF16, que são 2 valores de 16 bits.

O problema do checkRep é que nos changesets não armazenamos apenas os caracteres, mas também o comprimento da mudança. A função length () do Javascript, entretanto, conta pares substitutos como 2, então, por exemplo, um emoji tem comprimento 2. Quando o mysql decodifica a string de um changeset para pontos de interrogação, nossa representação de um changeset não é mais válida.

Substituí-lo por dois pontos de interrogação é um hack e não uma solução real porque não temos ideia de qual ponto de código o usuário inseriu em primeiro lugar (mas contanto que o valor esteja no cache do ueberDB, poderíamos retirá-lo de lá).

produziria resultados errados se alguém realmente usasse quatro pontos de interrogação (nosso valor de comprimento indicaria 4, se substituíssemos por 2 pontos de interrogação obteríamos um erro checkRep em retorno), portanto, se quiséssemos automatizar um script de reparo, precisaríamos verificar se o comprimento da string após a aplicação de nossa alteração estiver em conformidade com o valor "quantos caracteres foram adicionados" do conjunto de alterações.

para circunscrever o problema se alguém realmente usou quatro pontos de interrogação e, adicionalmente, pontos de código como emoji, também precisamos rastrear a posição dentro do documento onde substituímos os pontos de interrogação.

Observe também que nem todo erro checkRep é causado por codificação quebrada

E, claro, o acima funcionou. IMPRESSIONANTE! Eu não posso te agradecer o suficiente. Espero que, com a correção da configuração em vigor, isso não aconteça novamente.

Eu queria saber se a depuração que você está fazendo é manualmente btw. Obter e comparar os changesets e seus comprimentos um por um manualmente ou se você tiver alguma forma mais automatizada de fazer isso. Acho que posso criar um de qualquer maneira, só por curiosidade

<3 @ webzwo0i Obrigado cara, você é incrível

@ webzwo0i Ultimamente , tenho feito um bom trabalho com a obtenção do representante de caractere de uma coordenada X em um elemento (para arrastar e soltar) e tenho a sensação de que vou encontrar esse problema em que certos caracteres estão mal embalados . Será interessante testar isso em algum momento

O erro pode ser facilmente reproduzido criando um novo pad com um único emoji (por exemplo, 🐼) e reiniciando o etherpad, consulte também # 3340.

Atualização : a partir de abril de 2019, este único emoji não quebra o teclado, mesmo depois de reiniciado.

Eu queria verificar todos os pads, então adicionei uma ferramenta checkAllPads (consulte PR # 3342).

O erro pode ser facilmente reproduzido criando um novo pad com um único emoji (por exemplo, panda_face) e reiniciando o etherpad, veja também # 3340.

Não consigo reproduzir isso, fazendo exatamente o que descrevi acima. Consulte https://etherpad.wikimedia.org/p/ohmy para obter um exemplo (sim, já reiniciei o etherpad várias vezes)

Acabamos de quebrar o pad com esse erro também. Curiosamente, checkPad,js não encontrou nenhum problema e repairPad.js executado até a conclusão sem consertá-lo. Existe alguma maneira de determinar qual revisão está com defeito?

EDIT: Ah, encontrei https://gist.github.com/marcelklehr/a78d293571e7f06e3cf9 que me apontou o caminho certo. Há alguma chance de isso ser incluído no próprio etherpad? Tem sido infinitamente útil agora, muito obrigado! (No entanto, eu tive que substituir console.log por console.error para até mesmo ver qualquer número de revisão. Não tenho nenhuma experiência em nodeJS, mas não consegui descobrir outra maneira de realmente ver todo o registro. )

Na verdade, fazer o "substituir ???? por ?? " ajudou aqui também. :) Parece que o último changeset foi alguém inserindo um emoji (terminou em $???? ).

No entanto, não entendo por que isso é classificado como um "bug menor". Este bug leva à perda total de um pad (até que alguém perceba a coisa /timeslider , que demorou uma semana em nosso caso, e mesmo assim o histórico está perdido).

Eu mesmo não fui designado, pois é improvável que consiga consertar isso. FWIW, esse bug parece ser devido a uma limitação da biblioteca easysync, que estou especulando não oferece suporte a todos os utf-8. (UTF-8 pode codificar um caractere como bytes múltiplos, que cada um adiciona ao comprimento de uma string em javascript, mesmo que seja apenas um caractere).

- deixa pra lá -: D

FWIW, esse bug parece ser devido a uma limitação da biblioteca easysync, que estou especulando não oferece suporte a todos os utf-8. (UTF-8 pode codificar um caractere como bytes múltiplos, que cada um adiciona ao comprimento de uma string em javascript, mesmo que seja apenas um caractere).

Na verdade, temos tremas (äöü) em nossos pads o tempo todo, que também são multibyte em UTF-8. Com base no que foi dito acima, acho que o problema é na verdade sobre UTF-16 - que, quando originalmente projetado, deveria ter exatamente 2 bytes por caractere (ponto de código, na verdade), mas agora que temos mais de 2 ^ 16 pontos de código - alguns precisam de 4 bytes, como emojis. E agora length() não corresponde mais ao número de pontos de código e tudo fica confuso.

Então, talvez uma solução melhor seja rejeitar completamente quaisquer pares substitutos (pontos de código de 4 bytes)? Isso tornaria impossível usar o etherpad com personagens do plano suplementar , mas provavelmente está quebrado de qualquer maneira, parece? E deve proteger o DB. Parece haver maneiras de testar pares substitutos em JS (mas não tenho nenhuma experiência em JavaScript moderno).

Por que isso foi fechado? Pelo que sei, o Etherpad ainda engasga com personagens fora do BMP. Recentemente, novamente tive que consertar manualmente uma almofada que se quebrou dessa maneira.

Fechei porque abri a edição 2014 e não tinha mais interesse.

Bem, ainda é um problema em aberto para outras pessoas, então agradeceria se você pudesse reabri-lo.

Obrigado! :)

Alguém tem algum exemplo de caractere (sequência) que quebra um bloco de forma confiável? Isso facilitaria a depuração, eu acho.

A biblioteca Easysync descreve o texto (e sua legenda) em termos de "caracteres", mas era um produto mínimo viável de 10 anos atrás. Hoje em dia, provavelmente devemos pensar em termos de pontos de código UTF-8 normalizados por NFC.

Apenas nos perguntando, poderíamos ser capazes de resolver o problema armazenando os valores ueberdb como blobs binários em vez de em uma coluna de texto agrupada?

Atualmente, se tentarmos colocar uma sequência de bytes que não é utf8mb4 válida (pense: um conjunto de alterações que contém parte de um caractere multibyte) em uma coluna utf8mb4 , há apenas dois resultados possíveis: ou o banco de dados recusa o entrada, ou cliente (ou servidor) precisa remover (pense: substituir por "?") os "caracteres" ou bytes inválidos antes.

Usando uma coluna binária de blob, o banco de dados não se importaria mais com a sequência de bytes utf8mb4 inválida, portanto, podemos evitar a substituição de caracteres. Se easysync for tão agnóstico quanto à codificação como eu entendo, isso pode funcionar (contanto que dois usuários não insiram caracteres multibyte AB e CD na mesma posição simultaneamente e estes acabam como changeset individuais A, C, B, D - neste pedido -, tornando o resultado mesclado inválido utf8mb4).

PS: Acabei de testar que inserir um caractere UTF8 de 4 bytes como 🍰 não é um problema em si (embora: eu não reiniciei ainda, o que pode ser uma explicação), então presumo que o bug requer simultaneidade (levando ao caractere sendo dividido em dois ou mais changesets que são inválidos por conta própria) ou requer que um cliente emita um changeset que remove parte de tal caractere.

Olá, também estamos enfrentando esse problema em vários blocos.

Estou tentando de tudo e não consigo substituir por 🍰, tentei reinicializações, back-ends de banco de dados diferentes (que estão configurados corretamente) ..

Alguém pode fornecer etapas para replicar com nossa base de código mais moderna?

Pressionar backspace em 🍰 substitui o item por , o que é obviamente péssimo.

Para mim, replace( value ,'????','??') sempre funcionou até agora. Mas não aconteceu por alguns meses.

Eu incluí uma versão atualizada do Check Pad Deltas que funciona, se as pessoas puderem tentar para ver se ajuda quando tiver esse problema eu agradeceria.

Ainda acho que o problema básico é que o modelo de dados Etherpad pensa em termos de "caracteres" e não de pontos de código UTF-8 normalizados.

A menos que reformulemos a biblioteca central, isso nunca será realmente resolvido. Obviamente, qualquer mitigação é útil. Apenas estou dizendo que não existem soluções _fácil_ que são 100% corretas na minha opinião.

Você ficaria surpreso com a quantidade de editores (e alguns muito populares entre os desenvolvedores) que têm uma experiência semelhante ao Etherpad embora. Brincando hoje, tive algumas experiências malucas.

Eu incluí uma versão atualizada do Check Pad Deltas que funciona, se as pessoas puderem tentar para ver se ajuda quando tiver esse problema eu agradeceria.

Puxado no branch master com # 3717 (14ae2ee95094).

Olá, estamos tendo um problema semelhante com um de nossos eletrodos.
@JohnMcLear, infelizmente, a versão mais recente do checkPadDeltas não ajudou: /

@gnd você tem uma instância pública?

Você pode clicar no url padId / export / etherpad e obter o arquivo .etherpad?

Você está executando o último desenvolvimento?

Qual é o seu back-end de banco de dados?

Tantas perguntas, forneça o máximo de detalhes possível

@JohnMcLear
Sim, é uma instância pública: https://pad.xpub.nl/p/CareCircle
Infelizmente recebo um erro de 502 Bad Gateway ao tentar obter o arquivo .etherpad
Estamos executando o último desenvolvimento (git pull origin) em nodejs 12.16.3-1nodesource1, com o backend db sendo 10.3.22-MariaDB-0 + deb10u1.

Estou disponível hoje para ajudá-lo com qualquer tipo de depuração que você queira fazer. Já experimentei a última versão do checkPadDeltas, no entanto, ele trava horas após o início. Esta é a única saída que ele fornece:

Todos os caminhos relativos serão interpretados em relação ao Etherpad base dir: / opt / etherpad
[2020-05-05 00: 04: 12.330] [DEBUG] AbsolutePaths - o caminho relativo "settings.json" pode ser reescrito para "/opt/etherpad/settings.json"
[2020-05-05 00: 04: 12.346] [DEBUG] AbsolutePaths - o caminho relativo "credentials.json" pode ser reescrito como "/opt/etherpad/credentials.json"
configurações carregadas de: /opt/etherpad/settings.json
Nenhum arquivo de credenciais encontrado em /opt/etherpad/credentials.json. Ignorando.
[2020-05-05 00: 04: 12.369] [INFO] console - Usando o tema "no-skin" em dir: / opt / etherpad / src / static / skins / no-skin
[2020-05-05 00: 04: 12.371] [INFO] console - Chave de sessão carregada de: /opt/etherpad/SESSIONKEY.txt
[2020-05-05 00: 04: 12.541] [ERROR] console - a mesa não está configurada com o conjunto de caracteres utf8 - Isso pode causar falhas quando certos caracteres são colados nos blocos
[2020-05-05 00: 04: 12.543] [INFO] console - RowDataPacket {character_set_name: 'utf8mb4'} utf8

Cara, o erro está no seu 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

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

@JohnMcLear
nosso banco de dados tem

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

Enquanto a mesa da loja tem

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

Devo converter usando
ALTER DATABASE etherpad_lite_db CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

?

@JohnMcLear

A configuração incorreta foi dupla, o banco de dados estava usando utf8 e utf8_general_ci, mas também no settings.json o conjunto de caracteres do banco de dados foi definido como "utf8". Tendo corrigido tudo para utf8mb4 ainda não ajudou, e o pad em questão não carrega, e o checkPadDeltas ainda trava:

Todos os caminhos relativos serão interpretados em relação ao Etherpad base dir: / opt / etherpad
[2020-05-05 13: 17: 43.443] [DEBUG] AbsolutePaths - caminho relativo "settings.json" pode ser reescrito para "/opt/etherpad/settings.json"
[2020-05-05 13: 17: 43.444] [DEBUG] AbsolutePaths - o caminho relativo "credentials.json" pode ser reescrito como "/opt/etherpad/credentials.json"
configurações carregadas de: /opt/etherpad/settings.json
Nenhum arquivo de credenciais encontrado em /opt/etherpad/credentials.json. Ignorando.
[2020-05-05 13: 17: 43.463] [INFO] console - Usando o tema "no-skin" em dir: / opt / etherpad / src / static / skins / no-skin
[2020-05-05 13: 17: 43.464] [INFO] console - Chave de sessão carregada de: /opt/etherpad/SESSIONKEY.txt

@gnd É um problema GiGo. Depois de colocar o lixo, ele não pode ser alterado. Agora tudo que você sabe é que o problema não vai aparecer no futuro!

@gnd É um problema GiGo. Depois de colocar o lixo, ele não pode ser alterado. Agora tudo que você sabe é que o problema não vai aparecer no futuro!

repairPad.js seria capaz de consertar essas almofadas quebradas?

Oh, oi @caugner - infelizmente não, o repairPad.js geralmente é uma droga e realmente não funciona. https://github.com/ether/etherpad-lite/blob/develop/bin/repairPad.js#L48

A melhor coisa que posso sugerir é puxar o texto / texto para fora do bloco e trazê-lo para um novo bloco.

@gnd eu posso escrever um script para testar e tentar obter o texto, se quiser?

bin/extractPadData.js com uma mudança na saída para stdout pode ser suficiente aqui .. 2 minutos vou criar um extractPadText.js

@JohnMcLear isso seria muito útil de fato)

Extraindo

Use node bin/extractPadData.js $padid
Então cat $padid.db | grep \"text\" | grep revNum | tail -1

O texto é o item val.atext.text , você poderia analisar json em cli .. Farei isso a seguir, se precisar .. Por enquanto, faça esses comandos certificando-se de substituir $ padid pelo seu PadID

Análise

sudo apt-get install jq para instalar o jq e então cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text para ver apenas o texto.

Para escrever o texto do Pad em um arquivo de texto cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text > $padid.txt

Agora que você tem o pad text, pode simplesmente colocá-lo em um arquivo de texto e importar ou definir a API de texto ou qualquer outra coisa ...

Deixe-me saber se a extração falhar e considerarei outra abordagem.

A extração está em execução, porém é bastante lenta. No arquivo CareCicle.db vejo a última linha em revs: 80 , enquanto o script já roda por 20m. O bloco em questões tem mais de 12 mil revisões.

Oh cara, isso é péssimo .. Acho que não consigo construir o objeto pad após 80 revisões .. Deve levar apenas 30 segundos ou mais para o script ser executado.

a última sugestão seria grande, despejar todo o banco de dados e enviá-lo para mim, e então posso escrever um script para analisar o que você precisa. Como alternativa, posso tentar escrever um script aqui, mas pode haver algumas idas e vindas para fazê-lo funcionar dessa maneira.

Olá @JohnMcLear , o script finalmente terminou. Não tenho ideia de por que demorou tanto (quase 40 horas). De qualquer forma, olhando para ele, me parece que todo o exercício pode ser feito selecionando a revisão mais alta que é divisível por 100 da tabela de armazenamento e extraindo o texto dela? No futuro, farei isso manualmente :) Muito obrigado pela sua ajuda

Exatamente isso, mas muitas vezes sou repreendido por nossos usuários quando suponho que eles podem realizar consultas ao banco de dados, então tento evitar isso. Acho que sei por que demorou tanto btw, você está usando o MySQL @ Etherpad 1.8.3?

Estou usando o master mais recente do git (não tenho certeza de qual versão é)

Supondo que o MySQL seja um bug conhecido, o patch será lançado hoje.

sim, desculpe, é o mais recente MariaDB - 10.3.22-MariaDB

@JohnMcLear, desculpe por

Não, mas apenas instale o npm [email protected] para corrigir

A propósito, a nova lógica para armazenar um texto adicional está em vigor, portanto, deve ser fechado, mas se as pessoas tiverem um problema, crie um novo problema e consulte este. Eu quero lidar com cada causa individual de problema caso a caso com o objetivo principal de criar uma lógica automatizada para restaurar um pad após detecção de corrupção em tempo real. Esse é o sonho, pois a corrupção é inevitável.

Esta é uma mensagem para as pessoas que começaram a fazer isso recentemente (ao atualizar de versões anteriores do etherpad).

Hoje eu atualizei um serviço etherpad de 1.6.3 para 1.8.6 (que mudança !!!!! parabéns a todos os desenvolvedores)

Tive problemas com um pad, os verificadores (checkPad, checkAllPads, etc.) não conseguiram detectá-lo (ou não sei como executar o nó corretamente, de qualquer maneira).

Eu verifiquei que charset é utf8mb4 em meu settings.json (vi a última versão em settings.json.template ).

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

para o caso https://pad.example.com/p/my-broken-pad eu fiz:

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

e funcionou de novo: tada:: unicórnio:: brilhos:

essa solução estava acima (coloquei um +1 nas mensagens anteriores com a solução para ajudar a encontrá-la), mas queria deixá-la mais clara

Acho que uma coisa que poderíamos fazer aqui é verificar ???? no conteúdo do bloco e fornecer um aviso que inclui uma solução sugerida. @ pedro-nonfree, por favor, envie um patch para checkPad.js ou algo assim, então eu ficaria feliz em mesclá-lo :)