Etherpad-lite: Неперехваченная ошибка: неудачное утверждение: неверный набор изменений (ошибка checkRep)

Попробуйте последнюю ветку разработки и сообщите нам, если это все еще происходит

Это нетривиально, так как это происходит случайно на prod-сервере у многих пользователей, и я не могу воспроизвести это.
Я могу только проверить, остаются ли сломанные колодки сломанными при проявке, если это помогает.

Да, пожалуйста

На следующей неделе я скопирую базу данных в dev. Сообщу как можно скорее. Спасибо за быстрый ответ.

К сожалению, при переходе к проявке поврежденные колодки не были восстановлены. Интересно, что при перемещении серверов (простой экспорт / импорт sql) одна из площадок «отремонтирована». Он работает на новом сервере (даже на 1.3.0), но другие повреждения не работают. Все та же ошибка.

Это действительно странная ошибка, и иногда кажется, что колодки просто «самовосстанавливаются» даже на PROD и без каких-либо изменений с нашей стороны.

Теоретически этой проблемы не должно возникать, так как плохие данные никогда не должны попадать внутрь.

Я могу оставить это открытым, и если это произойдет со свежими данными, мы можем попытаться решить эту проблему.

Что вы имеете в виду под «свежими данными»? Нужно ли мне ставить ПРОД на проявку и пытаться получить новые сломанные колодки?

Хм, это было бы потенциально болезненно ... Может быть, подождать 1.4, которая должна выйти максимум через несколько недель.

Мы можем это сделать. Большое спасибо.

У меня тоже есть эта проблема, с той же странной случайностью. Я обновился до etherpad-lite 1.4, и он все еще там. URL одной из планшетов http://etherpad.usabilido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4

Я сейчас нахожусь в процессе обновления до 1.4 и, надеюсь, буду работать с новой версией, так что я могу проверить, появляются ли новые дефекты в новых планшетах после запуска новой версии.

@usabilidoido вы можете сказать своим пользователям экспортировать-импортировать панель. Вы можете получить доступ к элементам управления, добавив / timeslider к URL-адресу, например: http://etherpad.usabilidoido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4 / timeslider

Экспортируйте как html, а затем импортируйте в новую панель.

Я столкнулся с этой проблемой в версии 1.4. На сломанных планшетах командная строка показывает [WARN] client - Uncaught TypeError: Cannot read property 'length' of undefined когда браузер показывает ошибку Failed assertion .

Совет от @ Ra1d3n по поводу обходного пути / timeslider. Рад видеть, что содержимое панели все еще доступно.

Это всего лишь догадка, но если хотите, попробуйте с экспериментальной веткой try/client-init-remove-checkRep я только что создал. (Обычно это опасно, но я думаю, что попробовать стоит.)

Прошил все до 1.4. а вчера у нас снова сломалась колодка. Возможно, он сломался до обновления, но я не уверен. Я буду искать.

@marcelklehr К сожалению, я не могу перенести рабочий сервер на _dangerous_ версию. И я не могу зеркалировать запросы на вторичный сервер, потому что у меня нет ресурсов. : - /

Извините, я не понял: не запускайте try/client-init-remove-checkRep в продакшене, а попробуйте получить доступ к сломанным контактным площадкам с помощью etherpad, запущенного в этой ветке.

Я удалил checkRep в этой ветке, потому что подозреваю, что в некоторых случаях нормализация может работать некорректно. Итак, когда сломанный пэд работает на этой ветке без каких-либо проблем, мы должны вернуться к этому методу.

@marcelklehr Я только что сделал, и, к сожалению, это не помогло.

Процесс:

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

Я подтвердил, что изменение действительно произошло в файловой системе. (есть комментарий и новая строка) Ошибка осталась прежней.

Я получил ошибку, о которой упоминала

консоль на сервере:

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

Когда я убиваю сервер, в клиенте также отображается сообщение:

Я мог бы предоставить вам SQL-импорт сломанной панели, но вам нужно будет сказать мне, что именно вам нужно сначала извлечь из базы данных. :-)

Фактическое содержимое панели будет очень полезно, так что это будет db key pad:<PADID> (http://etherpad.org/doc/v1.4.0/#index_pad_padid) и, возможно, несколько последних изменений.

Я думаю, что подхожу ближе:

checkPad говорит:

$ 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

Несоответствие применения во всех случаях означает, что рассматриваемая ревизия ожидала на один символ меньше, чем фактически присутствует (то есть, один неожиданный символ). Изучив дамп базы данных, я обнаружил, что все эти ревизии следуют за ревизией с прикрепленным к ней текстом (не все ревизии включают полное содержимое панели, а вместо этого только дельту, однако, время от времени из соображений производительности полное содержимое прилагаются).

По-видимому, что-то пошло не так с этим метасвойством либо при сохранении ревизии, либо при создании текущего текста для нового клиента пэда.

Я просто переписал checkPad, чтобы использовать вычисленный текст вместо кешированного, и планшет проходит. Даже кешированные atexts верны! Это заставляет меня думать, что есть ошибка в каком-то алгоритме, который вычисляет полный текст для client_vars!

Хорошая работа, Марсель. Похоже, вы близки к решению этой проблемы.

Ах, это не генератор client_vars. Нарушен алгоритм, отвечающий за создание кешированного текста.

@ Ra1d3n В качестве быстрого исправления вы можете оживить ваши сломанные планшеты, удалив мета-свойство atext из всех ключевых ревизий (где revNo % 100 == 0 ). «Повторная вставка» всех записей, связанных со сломанной колодкой, давным-давно сообщалось как решение аналогичных проблем - теперь мы знаем, почему это работает :)

@marcelklehr Заставит ли это EP перестроить пэд с версии 0 при загрузке? Думаю, тогда мне не стоит обойтись удалением всех свойств atext из всех ревизий ... :-) Есть ли надежда на сценарий "регенерировать Pad", который перестраивает ключевые ревизии с правильным алгоритмом?

Я внес некоторые изменения в скрипт checkPad. Смотрите здесь: # 1653
Но это скорее грязный прием. Если мой скрипт решит эту проблему, я напишу скрипт для исправления колодок.

Круто, я с нетерпением жду этого. Прямо сейчас мы получаем только одну сломанную подушечку в неделю, поэтому я склонен дождаться исправления. :-) Благодаря.

Да, я думал о сценарии.

Итак, разница между вычисленным и кешированным текстом показывает, что: «концертов» каким-то образом превратились в «ко цертов». В другой редакции «з» также было преобразовано в « » ...

Я не знаю, о чем это. Эти символы находятся в Unicode BMP, afaik, поэтому я не знаю, что с ними случилось.

Мутации в панели @ Ra1d3n происходят в ключевых ревизиях 4900, 11400, 12300 и 13600 (каждая сотая оборот является ключевой, что означает, что он будет кэшировать все содержимое панели). Кроме того, AttributedText, хранящийся в записи пэда, тоже поврежден. Все остальные ключевые изменения в порядке. (проанализировано этим скриптом )

Символы кажутся случайными. На самом деле ничего не торчит. Я не вижу закономерности.

Я подозреваю, что что-то пошло не так при сохранении AttributedText в базе данных. Поскольку иногда пэд восстанавливается между ревизиями сломанного ключа, я предполагаю, что сохраненный в памяти текст хорош. Однако иногда, когда он хранится в базе данных, он каким-то образом повреждается. Если авторы продолжат редактировать документ до тех пор, пока не будет создана следующая ревизия ключа и эта ревизия не будет повреждена, то никто ничего не заметит.
Однако, если сервер завершает работу _ до_ управления для успешного сохранения действительного AText, хранящегося в памяти, в базу данных, панель будет сломана при следующем запуске сервера.

@marcelklehr У нас был сбой etherpad и несколько раз восстановление из-за плагина, который не был хорошо закодирован, может ли это быть причиной? Странно, что каждый раз повреждалась только одна буква.

Я создал сценарий для повторной вставки всех значений базы данных планшета. На моих сломанных блокнотах сценарий не работал.
@ Ra1d3n Вы можете скачать скрипт здесь: https://github.com/Gared/etherpad-lite/blob/pad-repair-script/bin/repairPad.js
Убедитесь, что ваш экземпляр etherpad не запущен, пока вы выполняете этот скрипт.

@Gared Откуда вы значения в своем скрипте? Я рекомендую поработать с моей вилкой checkPad, настроив ее для вставки повторно вычисленных значений AttributedText в базу данных.

Я бы сказал, что сбои @ Ra1d3n Etherpad вряд ли

@marcelklehr Вероятно, это просто сделало проблему более заметной, потому что в этих случаях мы теряли правильное значение памяти.

@marcelklehr Этот скрипт является ответвлением скрипта extractPadData. Значения и ключи загружаются в функцию выше. Это все клавиши пэда.

Скрипт repairPad.js от @Gared исправляет мои сломанные колодки. Есть ли шанс, что это исправление будет включено в следующую версию etherpad-lite?

Конечно, просто отправьте с ним запрос на перенос или попросите

Открытый запрос на включение # 2210.

Мой etherpad работает на 1.4.1, и у меня трижды возникала одна и та же проблема, описанная выше: планшет не может загружаться, но / timeslider работает хорошо.
2 из них сейчас запускаются повторно, ничего не делая.
На третьем планшете безуспешно пробовал repairPad.js. Его URL-адрес: +1: http://portail.univ-lille1.fr/etherpad/link.jsp?groupID=g.jfobkKVrkydeTwLY&padID=SES_Grp8_Macroeconomie (для доступа к самокат.

Может быть, есть набор изменений с ненормальным значением, которое не принимается во внимание RepairPad, или есть какой-либо новый выпуск reparPad.js, который я не видел на git?

Мы думаем, что теперь у нас есть решение. Пожалуйста, потяните разработку и тестирование :) Спасибо!

Здравствуйте, это только что произошло. Мы запускаем 1.5.7, это последняя выпущенная версия. Backend - это база данных MySQL. У меня нет указаний на действия пользователя, которые могли вызвать это.

Рассматриваемый планшет: https://etherpad.wikimedia.org/p/iOS-iteration-planning

Получение данных пэда с помощью трюка таймлайдера работает нормально. Пэд, однако, никогда не загрузится.

Все, что есть в базе данных, можно выгрузить и предоставить для отладки, если это поможет.

привет, у меня было это обсуждение утром.
08:47 <webzwo0i> mutante: я отладил пэд. обычно вы не должны этого делать, но если у вас есть резервная копия базы данных (и после выполнения экспорта / etherpad, чтобы иметь резервную копию
панель), вы можете изменить три записи в базе данных, и панель снова должна работать нормально. три команды mysql:

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> вы можете проверить, работает ли ваша база данных с кодировкой utf8mb4 или utf8?
08:51 <webzwo0i> Ой, пожалуйста, не применяйте команды mysql. может быть я немного постился :-) нужно что-то сначала проверить
09:08 <webzwo0i> м-м нет, должно быть все в порядке, пожалуйста, проверьте ... было бы хорошо знать, запустили ли вы последнюю версию или что-то еще, и какие плагины вы включили
09:47 <webzwo0i> Я не знаю, знакомы ли вы, люди в Викимедиа, но если вы можете узнать, кто такой пользователь «Брайан», не могли бы вы спросить его, какой браузер он использует? в
Причина в том, что я вижу, что это за ошибка, но я не могу вызвать ее в своем браузере (только вручную, но поскольку вы не настроены враждебно, вероятно, не было
цель)
09:49 <webzwo0i> (так что у нас, вероятно, есть две ошибки, одна на стороне сервера и одна на стороне клиента)

мне нужна информация, если ваша база данных utf8 или utf8mb4
Я извлек оскорбительный набор изменений, таймлайдер не будет работать с этими изменениями, если вы также не примените

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

вместе с обновлениями, приведенными выше, это должно сделать ваш планшет снова пригодным для повторного использования

@ webzwo0i

Да, я заметил, что этот мутанте разговаривал с тобой. Я просто решил заняться проблемой github. Я выясню, кто такой «Брайан» и какой браузер они используют для вас.

Итак, таблица store уже довольно давно является utf8mb4. Это был utf8, но мы преобразовали его в utf8mb4 из-за другого набора проблем еще в июне. В частности, 23 июня 2015 г.

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

не нужно выяснять пользователя / браузер, теперь я могу воспроизвести ошибку. благодарю вас!

Поскольку у вас последняя версия, вам необходимо вставить «charset»: «utf8mb4» в settings.json внутри dbSettings. Теперь он находится в settings.json.template. Вы можете проверить, нужно ли это, с помощью

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

клиент (и, возможно, соединение?) должен указывать utf8mb4, если не ваши таблицы базы данных могут хранить 4 байта utf8, но сервер не ожидает 4 байта utf8 для клиентского соединения.
Это не отремонтирует ваши старые колодки. Однако вы можете перебрать все свои планшеты и использовать bin / checkPad.js, чтобы понять, у скольких и у каких планшетов могут быть похожие проблемы. В зависимости от обстоятельств его можно очень легко отремонтировать (хотя некоторые символы будут сломаны), как в приведенном выше случае. Если есть много сломанных колодок, возможно, имеет смысл автоматизировать это.

Причина, по которой эти проблемы не видны, когда люди на самом деле пишут, заключается в том, что большинство сайтов используют внутренний кеш ueberDB для повышения производительности. Этот кеш на чистом javascript полностью поддерживает Unicode. Как только кеш будет очищен или перезапущен etherpad, он должен получить записи из базы данных.

Я отремонтировал колодку, как вы сказали. Интересно узнать, что 4 знака вопроса подряд могут повредить PAD таким образом. И что разрушающий набор изменений будет таким старым по сравнению с кончиком планшета. Но ваше объяснение имеет смысл, спасибо за это.

Я также обновил конфигурацию с помощью "charset": "utf8mb4".

Я слежу за билетом фабрикатора на Викимедиа, но у меня нет там учетной записи, поэтому я размещаю его здесь.

Вторую сломанную колодку также можно отремонтировать с помощью:

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

4 вопросительных знака являются признаком того, что, iirc, отдельные байты в четырехбайтовом UTF8 не являются допустимыми UTF8. (В UTF8 только первые 127 символов представлены как одиночные байты, многобайтовый UTF8, вероятно, использует байты выше 0x7f). Таким образом, 4 вопросительных знака на самом деле представляют одну 4-байтовую закодированную строку UTF8, которая представляет собой кодовую точку за пределами базовой многоязычной плоскости (скорее всего, это смайлик :-D). В Javascript эти кодовые точки будут закодированы с использованием суррогатных пар UTF16, которые представляют собой 2 16-битных значения.

Проблема checkRep в том, что в наборах изменений мы сохраняем не только символы, но и длину изменения. Однако функция Javascript length () считает суррогатные пары как 2, поэтому, например, длина смайлика равна 2. Когда mysql декодирует строку набора изменений в вопросительные знаки, наше представление набора изменений больше не действует.

Замена его двумя вопросительными знаками - это взлом, а не реальное решение, потому что мы не знаем, какую кодовую точку ввел пользователь в первую очередь (но пока значение находится в кеше ueberDB, мы можем получить его оттуда).

это приведет к неверным результатам, если кто-то на самом деле использует четыре вопросительных знака (наше значение длины будет равно 4, если мы заменим его двумя вопросительными знаками, мы получим взамен ошибку checkRep), поэтому, если мы автоматизируем сценарий восстановления, нам нужно будет проверить если длина строки после применения нашего изменения соответствует значению "сколько символов добавлено" набора изменений.

Чтобы устранить проблему, если кто-то на самом деле использовал четыре вопросительных знака и дополнительно кодовые точки, такие как эмодзи, нам также нужно отслеживать положение внутри документа, где мы заменяем вопросительные знаки.

также обратите внимание, что не каждая ошибка checkRep вызвана неправильной кодировкой

И, конечно же, все вышеперечисленное сработало. ЗДОРОВО! Я не могу тебя отблагодарить. Я надеюсь, что с исправлением конфигурации это больше не повторится.

Мне было интересно, выполняется ли отладка вручную, кстати. Получение и сравнение наборов изменений и их длины вручную или если у вас есть более автоматизированный способ сделать это. Полагаю, я все равно могу создать свой, просто из любопытства

<3 @ webzwo0i Спасибо, чувак, ты

@ webzwo0i В последнее время я координаты X на элементе (для перетаскивания), и у меня есть ощущение, что я столкнусь с этой проблемой, когда определенные символы неправильно обернуты . Будет интересно проверить, что в какой-то момент

Ошибка может быть легко воспроизведена путем создания нового пэда с одним эмодзи (например, 🐼) и перезапуска etherpad, см. Также # 3340.

Обновление : по состоянию на апрель 2019 года этот единственный смайлик не ломает панель даже после перезапуска.

Я хотел проверить все колодки, поэтому добавил инструмент checkAllPads (см. PR # 3342).

Ошибка может быть легко воспроизведена путем создания нового пэда с одним смайликом (например, panda_face) и перезапуска etherpad, см. Также # 3340.

Я не могу воспроизвести это, делая именно то, что описано выше. См. Пример на https://etherpad.wikimedia.org/p/ohmy (да, я уже несколько раз перезапускал etherpad)

У нас только что сломалась колодка из-за этой ошибки. Любопытно, что checkPad,js не обнаруживает никаких проблем, а repairPad.js выполняется до завершения, не исправляя его. Есть ли способ определить, какая версия неисправна?

РЕДАКТИРОВАТЬ: Ах, я нашел https://gist.github.com/marcelklehr/a78d293571e7f06e3cf9, который указал мне правильный путь. Есть ли шанс, что это может быть включено в сам etherpad? Это было бесконечно полезно прямо сейчас, большое спасибо! (Однако мне пришлось заменить console.log на console.error чтобы даже увидеть какие-либо номера ревизий. У меня вообще нет опыта работы с nodeJS, но я не мог придумать другого способа действительно увидеть все журналы. )

Действительно, здесь тоже помогло "заменить ???? на ?? ". :) Похоже, что последней ревизией кто-то вставил смайлик (он заканчивался на $???? ).

Однако я не понимаю, почему это классифицируется как «незначительная ошибка». Эта ошибка приводит к полной потере пэда (пока кто-то не заметит /timeslider , что в нашем случае заняло неделю, и даже тогда история теряется).

Я не назначен, так как вряд ли я смогу это исправить. FWIW, эта ошибка, по-видимому, связана с ограничением библиотеки easysync, которая, как я предполагаю, не поддерживает все utf-8. (UTF-8 может кодировать один символ как несколько байтов, каждый из которых увеличивает длину строки в javascript, даже если это всего лишь один символ.)

- забудь -: D

FWIW, эта ошибка, по-видимому, связана с ограничением библиотеки easysync, которая, как я предполагаю, не поддерживает все utf-8. (UTF-8 может кодировать один символ как несколько байтов, каждый из которых увеличивает длину строки в javascript, даже если это всего лишь один символ.)

На самом деле у нас все время есть умляуты (äöü) в наших блокнотах, которые также являются многобайтовыми в UTF-8. Основываясь на том, что было сказано выше, я думаю, что проблема на самом деле связана с UTF-16, который при первоначальной разработке должен был иметь ровно 2 байта на символ (кодовая точка, на самом деле), но теперь, когда у нас есть более 2 ^ 16 кодовых точек, некоторые из которых требуют 4 байта, например смайлики. И теперь length() больше не соответствует количеству кодовых точек, и все запутывается.

Так, может быть, лучшим решением будет полный отказ от любых суррогатных пар (4-байтовых кодовых точек)? Это сделало бы невозможным использование etherpad с персонажами из дополнительного уровня , но, похоже, это все равно сломано? И он должен защищать БД. Кажется, есть способы проверить суррогатные пары в JS (но у меня нет опыта в современном JavaScript).

Почему это закрылось? Насколько мне известно, Etherpad все еще подавляется персонажами за пределами BMP. Недавно мне снова пришлось вручную ремонтировать колодку, которая так сломалась.

Я закрыл его, потому что открыл Выпуск 2014 и меня это больше не интересовало.

Что ж, это все еще нерешенная проблема для других, поэтому я буду признателен, если вы откроете ее снова.

Благодаря! :)

Есть ли у кого-нибудь пример символа (последовательности), который надежно ломает блокнот? Думаю, это облегчило бы отладку.

Библиотека Easysync описывает текст (и его длину) в терминах «символов», но это был минимально жизнеспособный продукт 10 лет назад. В настоящее время нам, вероятно, следует мыслить категориями кодовых точек UTF-8, нормализованных по NFC.

Просто интересно, сможем ли мы решить проблему, сохранив значения ueberdb как двоичные капли, а не в сопоставленном текстовом столбце?

В настоящее время, если мы попытаемся поместить последовательность байтов, которая недействительна utf8mb4 (подумайте: набор изменений, содержащий часть многобайтового символа), в столбец utf8mb4 , есть только два возможных результата: либо база данных отклонит input, или клиент (или сервер) должен удалить (подумайте: замените на "?") недопустимые "символы" или байты раньше.

Используя двоичный столбец blob, база данных больше не будет заботиться о том, что последовательность байтов является недопустимой, utf8mb4, поэтому мы можем избежать замены символов. Если easysync настолько агностик кодирования, насколько я понимаю, это может сработать (пока два пользователя не вставляют многобайтовые символы AB и CD в одну и ту же позицию одновременно, и они заканчиваются как отдельные изменения A, C, B, D - в этом order -, что делает объединенный результат недействительным utf8mb4).

PS: Я только что проверил, что вставка 4-байтового символа UTF8, такого как 🍰, сама по себе не проблема (хотя: я еще не перезапускал, что может быть объяснением), поэтому я предполагаю, что ошибка требует параллелизма (что приводит к тому, что символ разделены на два или более набора изменений, которые недействительны сами по себе), или для этого требуется, чтобы клиент испустил набор изменений, который удаляет часть такого символа.

Привет, мы тоже сталкиваемся с этой проблемой на многих планшетах.

Я пробую все и просто не могу заменить это на 🍰, я пробовал перезапускать, разные бэкэнды базы данных (которые правильно настроены) ..

Может ли кто-нибудь предложить шаги по воспроизведению с нашей более современной кодовой базой?

Нажатие Backspace на 🍰 заменяет элемент на , что, очевидно, отстой.

Для меня replace( value ,'????','??') до сих пор всегда работало. Однако этого не происходило уже несколько месяцев.

Я включил обновленную версию Check Pad Deltas, которая работает, и если люди могут попробовать, чтобы увидеть, помогает ли это при возникновении этой проблемы, я был бы признателен.

Я по-прежнему считаю, что основная проблема заключается в том, что модель данных Etherpad мыслит в терминах «символов», а не нормализованных кодовых точек UTF-8.

Пока мы не переработаем основную библиотеку, это никогда не будет решено. Очевидно, любое смягчение последствий полезно. Просто говорю, что не существует _легких_ решений, которые, на мой взгляд, гарантированно были бы правильными на 100%.

Вы будете удивлены, сколько редакторов (и очень популярных среди разработчиков) имеют опыт, аналогичный Etherpad. Играя сегодня, у меня были сумасшедшие переживания.

Я включил обновленную версию Check Pad Deltas, которая работает, и если люди могут попробовать, чтобы увидеть, помогает ли это при возникновении этой проблемы, я был бы признателен.

Заехал в ветку master с # 3717 (14ae2ee95094).

Привет, у нас возникла аналогичная проблема с одним из наших планшетов.
@JohnMcLear, к сожалению, последняя версия checkPadDeltas не помогла: /

@gnd у вас есть публичный экземпляр?

Можете ли вы нажать URL-адрес padId / export / etherpad и получить файл .etherpad?

У вас последняя разработка?

Какая у вас база данных?

Так много вопросов, пожалуйста, опишите как можно подробнее

@JohnMcLear
Да, это общедоступный экземпляр: https://pad.xpub.nl/p/CareCircle
К сожалению, я получаю ошибку 502 Bad Gateway, пытаясь получить файл .etherpad.
Мы запускаем последнюю разработку (git pull origin) на nodejs 12.16.3-1nodesource1, а бэкэнд db - 10.3.22-MariaDB-0 + deb10u1.

Я доступен сегодня, чтобы помочь вам с любой отладкой, которую вы, возможно, захотите сделать. Я уже пробовал последнюю версию checkPadDeltas, но она просто зависает в течение нескольких часов после запуска. Это единственный вывод, который он дает:

Все относительные пути будут интерпретироваться относительно идентифицированного базового каталога Etherpad: / opt / etherpad
[2020-05-05 00: 04: 12.330] [DEBUG] AbsolutePaths - Относительный путь «settings.json» можно переписать в «/opt/etherpad/settings.json»
[2020-05-05 00: 04: 12.346] [DEBUG] AbsolutePaths - Относительный путь credentials.json можно переписать в /opt/etherpad/credentials.json
настройки загружаются из: /opt/etherpad/settings.json
Файл учетных данных не найден в /opt/etherpad/credentials.json. Игнорирование.
[2020-05-05 00: 04: 12.369] Консоль [INFO] - Использование скина "no-skin" в каталоге: / opt / etherpad / src / static / skins / no-skin
[2020-05-05 00: 04: 12.371] Консоль [INFO] - сеансовый ключ загружен из: /opt/etherpad/SESSIONKEY.txt
[2020-05-05 00: 04: 12.541] Консоль [ERROR] - таблица не настроена с кодировкой utf8 - это может привести к сбоям при вставке определенных символов в контактные площадки
[2020-05-05 00: 04: 12.543] Консоль [INFO] - RowDataPacket {character_set_name: 'utf8mb4'} utf8

Чувак, ошибка в твоем логе!

[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

См. Https://github.com/ether/etherpad-lite/issues/3959

@JohnMcLear
наш БД имеет

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

В то время как в таблице магазина есть

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

Так следует ли мне конвертировать, используя
ALTER DATABASE etherpad_lite_db CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

?

@JohnMcLear

Неправильная конфигурация была двоякой: база данных использовала utf8 и utf8_general_ci, но также в settings.json кодировка для базы данных была установлена ​​как «utf8». Исправив все это в utf8mb4, все еще не помогло, и рассматриваемая панель не загружается, а checkPadDeltas все еще зависает:

Все относительные пути будут интерпретироваться относительно идентифицированного базового каталога Etherpad: / opt / etherpad
[2020-05-05 13: 17: 43.443] [DEBUG] AbsolutePaths - Относительный путь «settings.json» можно переписать в «/opt/etherpad/settings.json»
[2020-05-05 13: 17: 43.444] [DEBUG] AbsolutePaths - Относительный путь credentials.json можно переписать в /opt/etherpad/credentials.json
настройки загружаются из: /opt/etherpad/settings.json
Файл учетных данных не найден в /opt/etherpad/credentials.json. Игнорирование.
[2020-05-05 13: 17: 43.463] Консоль [INFO] - Использование скина «no-skin» в каталоге: / opt / etherpad / src / static / skins / no-skin
[2020-05-05 13: 17: 43.464] Консоль [INFO] - сеансовый ключ загружен из: /opt/etherpad/SESSIONKEY.txt

@gnd Это проблема GiGo. Если у вас есть мусор, его нельзя изменить. Теперь все, что вы знаете, это то, что проблема не появится в будущем!

@gnd Это проблема GiGo. Если у вас есть мусор, его нельзя изменить. Теперь все, что вы знаете, это то, что проблема не появится в будущем!

Разве repairPad.js не смог бы починить эти сломанные колодки?

О, привет @caugner - к сожалению, нет, repairPad.js вообще отстой и не работает. https://github.com/ether/etherpad-lite/blob/develop/bin/repairPad.js#L48

Лучшее, что я могу предложить, - это вытащить текст / текст из панели и перенести его на новую панель.

@gnd Я могу написать вам сценарий для тестирования, чтобы попытаться получить текст, если хотите?

bin/extractPadData.js с изменением вывода на стандартный вывод может быть здесь достаточно .. 2 минуты я создам extractPadText.js

@JohnMcLear , это действительно было бы очень полезно)

Извлечение

Используйте node bin/extractPadData.js $padid
Тогда cat $padid.db | grep \"text\" | grep revNum | tail -1

Текст представляет собой элемент val.atext.text , вы можете json проанализировать его на cli .. Я сделаю это дальше, если вам это нужно .. А пока выполните эти команды, убедившись, что вы заменили $ padid своим PadID

Парсинг

sudo apt-get install jq для установки jq, затем cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text для просмотра только текста.

Чтобы записать текст Pad в текстовый файл cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text > $padid.txt

Теперь у вас есть текстовый блокнот, который вы можете просто поместить в текстовый файл и импортировать, или вы установите API текста или что-то еще ...

Дайте мне знать, если извлечение не удастся, и я рассмотрю другой подход.

Добыча идет, но довольно медленно. В файле CareCicle.db я вижу последнюю строку на revs: 80 , в то время как скрипт уже работает в течение 20 минут. Блокнот в вопросах имеет более 12к ревизий ..

Ой, это отстой ... Я думаю, он не может построить объект pad после 80 ревизий ... Для запуска сценария должно потребоваться всего 30 секунд или около того.

последнее предложение было бы большим: сбросить всю базу данных и отправить ее мне, а затем я могу написать сценарий для анализа того, что вам нужно. В качестве альтернативы я могу попробовать написать здесь сценарий, но, возможно, придется кое-что сделать, чтобы заставить его работать таким образом.

Привет, @JohnMcLear , скрипт наконец-то завершен. Понятия не имею, почему это заняло так много времени (почти 40 часов). В любом случае, когда я смотрю на это, мне кажется, что все упражнение можно выполнить, выбрав самую высокую ревизию, которая делится на 100, из таблицы хранилища и извлекая из нее текст? В дальнейшем буду делать это вручную :) Большое спасибо за помощь

Именно так, но наши пользователи часто ругают меня, когда я предполагаю, что они могут выполнять запросы к базе данных, поэтому я стараюсь этого избегать. Думаю, я знаю, почему это заняло так много времени, кстати, вы используете MySQL @ Etherpad 1.8.3?

Я использую последнюю версию мастера от git (не уверен, какая это версия)

Предполагая, что MySQL это известная ошибка, мы должны выпустить исправления сегодня.

да, извините, последняя версия MariaDB - 10.3.22-MariaDB

@JohnMcLear, извините за спам этого билета, но есть ли у вас проблема с патчем MySQL, который вы упомянули? Я хочу посмотреть, могут ли с его помощью решить наши проблемы с производительностью с etherpad .. спасибо

Нет, просто выполните npm install [email protected], чтобы исправить

Между прочим, существует новая логика для хранения дополнительного текста, поэтому его следует закрыть, но если у людей возникнет проблема, создайте новую проблему и обратитесь к этой. Я хочу разбираться с каждой отдельной причиной проблемы в каждом конкретном случае с основной целью создать автоматическую логику для восстановления панели после обнаружения повреждения в реальном времени. Это мечта, поскольку коррупция неизбежна.

Это сообщение для людей, которые недавно пришли к этому (при обновлении со старых версий etherpad).

Сегодня я обновил службу etherpad с 1.6.3 до 1.8.6 (какое изменение !!!!! Поздравляем всех разработчиков)

У меня были проблемы с одним планшетом, средства проверки (checkPad, checkAllPads и т. Д.) Не смогли его обнаружить (или я не знаю, как правильно запустить узел).

Я подтвердил, что charset - это utf8mb4 в моем settings.json (последнюю версию видел в settings.json.template ).

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

для случая https://pad.example.com/p/my-broken-pad я сделал:

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

и это снова сработало: tada:: unicorn:: sparkles:

это решение было выше (я поставил +1 в предыдущих сообщениях с решением, чтобы помочь найти его), но я хотел, чтобы оно было более понятным

Я думаю, что мы могли бы сделать здесь одно - проверить ???? в содержимом блокнота и предоставьте предупреждение с предлагаемым решением. @ pedro-nonfree, пожалуйста, не могли бы вы отправить патч на checkPad.js или что-то в этом роде, тогда я с радостью объединю его :)