Etherpad-lite: キャッチされないエラー：失敗したアサーション：無効な変更セット（checkRepが失敗しました）

最新のDevelopブランチを試して、それがまだ発生するかどうかをお知らせください

これは、多くのユーザーがいるprodサーバーで偶然に発生し、再現できないため、簡単ではありません。
壊れたパッドが開発時に壊れたままであるかどうかをテストできるのは、それが役立つ場合だけです。

はい、お願いします

来週、dbをdevにコピーします。 できるだけ早く報告します。 迅速な対応ありがとうございます。

残念ながら、開発に移行しても、損傷したパッドは修復されていません。 興味深いことに、サーバーの移動（単純なSQLエクスポート/インポート）により、パッドの1つが「修復」されました。 新しいサーバー（1.3.0でも）で動作しますが、他のダメージパッドは動作しません。 それでも同じエラー。

これは本当に奇妙なバグであり、パッドはPRODでも「自己修復」しているように見え、私たちから何の変更もありません。

理論的には、この問題はまったく発生しないはずです。悪いデータが今ではその方法を見つけることができないからです。

これは開いたままにしておくことができ、新しいデータで発生した場合は、解決を試みることができます。

「新鮮なデータ」とはどういう意味ですか？ PRODを開発に投入して、新しい壊れたパッドを入手する必要がありますか？

うーん、それは潜在的に痛みを伴うでしょう..多分最大数週間で出るはずの1.4を待つでしょう。

私たちはそれをするかもしれません。 どうもありがとう。

私も同じ奇妙なランダム性でその問題を抱えています。 私はetherpad-lite1.4にアップデートしましたが、まだそこにあります。 パッドの1つのURL http://etherpad.usabilidoido.com.br 8080 / P / 07318a9b2b5666637d870fc50656323620af4df4：

現在、1.4にアップグレードしており、新しいバージョンで稼働できるようになっていることを願っています。新しいバージョンで実行した後、新しいパッドに新しい欠陥が発生するかどうかを確認できます。

@usabilidoidoパッドをエクスポート-インポートするようにユーザーに指示できます。 次のようにURLに/ timesliderを追加することで、コントロールにアクセスできます： http ：//etherpad.usabilidoido.com.br：8080 / p / 07318a9b2b5666637d870fc50656323620af4df4 / timeslider

HTMLとしてエクスポートしてから、新しいパッドにインポートします。

1.4でこの問題が発生しています。 壊れたパッドでは、ブラウザにFailed assertionエラーが表示されると、コマンドラインに[WARN] client - Uncaught TypeError: Cannot read property 'length' of undefinedが表示されます。

/ timesliderの回避策については、 @ Ra1d3nへのヒントをご覧ください。 パッドのコンテンツがまだそこにアクセスできるのを見てうれしいです。

これは単なる予感ですが、必要に応じて、先ほど作成した実験的なtry/client-init-remove-checkRepブランチを試してみてください。 （これは一般的に危険なことですが、試してみる価値はあると思います。）

すべてを1.4にアップグレードしました。 そして昨日、私たちは再び壊れたパッドを持っていました。 更新前に壊れたものかもしれませんが、よくわかりません。 私は探し続けます。

@marcelklehr残念ながら、本番サーバーを_dangerous_バージョンに移動することはできません。 また、リソースがないため、リクエストをセカンダリサーバーにミラーリングできません。 ：-/

申し訳ありませんが、はっきりしませんtry/client-init-remove-checkRepた。本番環境では

場合によっては正規化が正しく機能しない可能性があるため、そのブランチの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'.

変更が実際にファイルシステムにあることを確認しました。 （コメントと改行があります）エラーは同じです。

@ericpediaが言及したエラーが発生しましたが、破損したパッド以外では発生しませんでした。

サーバー上のコンソール：

[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

すべての場合に適用が一致しないということは、問題のチェンジセットが実際に存在する文字よりも1文字少ないことを期待していることを意味します（つまり、予期しない文字が1つあります）。 データベースダンプを調べたところ、これらのチェンジセットはすべて、テキストが添付されたリビジョンに従っていることがわかりました（すべてのリビジョンに完全なパッドの内容が含まれているわけではなく、デルタのみが含まれていますが、パフォーマンス上の理由から、完全な内容が含まれていることがよくあります添付されています）。

おそらく、リビジョンを保存するとき、または新しいパッドクライアントの現在のテキストを作成するときに、このメタプロパティで問題が発生しました。

checkPadを書き直して、キャッシュされたテキストの代わりに計算されたテキストを使用すると、パッドが渡されます。 キャッシュされたテキストでさえ正しいです！ これにより、client_varsの完全なテキストを計算するアルゴリズムにバグがあると思います。

これまでのところ、Marcelは素晴らしい仕事をしています。 あなたはこれを解決しようとしているようですね。

ああ、それはclient_varsジェネレーターではありません。 キャッシュされたテキストの作成を担当するアルゴリズムが壊れています。

@ Ra1d3nクイックフィックスとして、すべての主要なリビジョン（ revNo % 100 == 0 ）からatextメタプロパティを削除することで、壊れたパッドを復活させることができます。 壊れたパッドに関連するすべてのレコードを「再挿入」することは、かなり前に同様の問題の修正として報告されました-今ではそれが機能する理由がわかりました:)

@marcelklehrこれにより、EPはロード時にリビジョン0からパッドを再構築しますか？ それなら、すべてのリビジョンからすべてのatextプロパティを削除するべきではないと思います... :-)正しいアルゴリズムでキーリビジョンを再構築する「パッドの再生成」スクリプトに期待はありますか？

checkPad-scriptにいくつかの変更を加えました。 ここを参照してください：＃1653
しかし、これはもっと汚いハックです。 スクリプトでこの問題が解決する場合は、パッドを修正するスクリプトを作成します

かっこいい、楽しみにしています。 現在、壊れたパッドは1週間に1つしかないので、適切に修正されるのを待つ傾向があります。 :-)ありがとう。

ええ、私は台本を考えていました。

したがって、計算されたテキストとキャッシュされたテキストの差分は、「концертов」がどういうわけか「ко цертов」に変わったことを示しています。 別の改訂では、「з」も「 」に変更されました...

これが何なのかわかりません。 これらの文字はUnicodeBMP、afaikに含まれているため、何が起こったのかわかりません。

@ Ra1d3nのパッドの変異は、キーリビジョンこのスクリプトで分析）

文字はランダムに飛んでいるようです。 本当に何も突き出ていません。 パターンが見当たりません。

AttributedTextをデータベースに保存するときに問題が発生したと思われます。 壊れたキーリビジョンの間にパッドが回復することがあるので、メモリに保存されているテキストは良いと思います。 ただし、データベースに保存すると、どういうわけか破損することがあります。 次の主要なリビジョンが作成されるまで作成者がドキュメントを編集し続け、そのリビジョンが破損することはない場合、誰も何も気付かないでしょう。
ただし、メモリに保持されている有効なATextをデータベースに正常に保存する前にサーバーをシャットダウンすると、次回のサーバー起動時にパッドが破損します。

@marcelklehrプラグインが適切にコーディングされていなかったため、etherpadがクラッシュして数回回復しましたが、これが原因でしょうか？ 毎回壊れたのはたった一文字だというのは不思議です。

パッドのすべてのデータベース値を再挿入するスクリプトを作成しました。 壊れたパッドでは、スクリプトが機能しませんでした。
@ Ra1d3nここからスクリプトをダウンロードできます： https ：
このスクリプトの実行中は、etherpadインスタンスが実行されていないことを確認してください。

@Garedスクリプトのどこから値を取得しますか？ checkPadフォークを調整して、再計算されたAttributedText値をデータベースに挿入することをお勧めします。

@ Ra1d3n Etherpadのクラッシュが、データの破損を引き起こす可能性は低いと思います。

@marcelklehrこれらの場合、正しいメモリ値が失われたため、おそらく問題がより明確になりました。

@marcelklehrこのスクリプトは、extractPadDataスクリプトからのフォークです。 値とキーは上記の関数にロードされます。 これらはすべてパッドのキーです。

@GaredからrepairPad.jsスクリプトは私の壊れたパッドを固定しています。 この修正が次のetherpad-liteバージョンに組み込まれる可能性はありますか？

プルリクエストを送信するか、 @ Garedに送信してください

プルリクエスト＃2210を開きました

私のetherpadは1.4.1で実行されており、上記と同じ問題が3回発生しています。パッドをロードできませんが、/ timesliderは正常に機能します。
それらのうちの2つは、何もせずに再実行されています。
3番目のパッドで、repairPad.jsを試しましたが失敗しました。 そのURLは：+1です： http ：//portail.univ-lille1.fr/etherpad/link.jsp？groupID = g.jfobkKVrkydeTwLY＆padID = SES_Grp8_Macroeconomie（「utilisezle padavecl'invitexy」をクリックしてアクセスしますパディットセルフ。

たぶん、repairPadで考慮されていない異常な値のチェンジセットがありますか、それともgitで見たことがないreparPad.jsの新しいリリースがありますか？

現在、これに対する修正があると思います。 開発とテストをプルしてください:)ありがとう！

こんにちは、私たちはちょうどこれが起こったところです。 最後にリリースされたバージョンである1.5.7を実行します。 バックエンドはMySQLデータベースです。 これを引き起こした可能性のあるユーザーアクションについては何も示していません。

問題のパッド： https ：

タイムスライダートリックを介してパッドデータを取得することは問題なく機能します。 ただし、パッドはロードされません。

データベース内のすべてのものをダンプして、役立つ場合はデバッグ用に提供できます。

こんにちは、私は午前中にこの議論をしました。
08:47 <webzwo0i>ミュータント：パッドをデバッグしました。 通常はこれを行うべきではありませんが、データベースのバックアップがある場合（およびエクスポート/エーテルパッドを作成した後、
パッド）3つのデータベースエントリを変更でき、パッドは再び正常に機能するはずです。 3つの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> oha upsmysql-commandsを適用しないでください。 多分私は少し速かったです:-)最初に何かをチェックする必要があります
09:08 <webzwo0i> mh nopeは問題ないはずです、テストしてください...最新のリリースか何か他のものを実行したかどうか、そしてどのプラグインを有効にしたかを知っておくとよいでしょう
09:47 <webzwo0i>ウィキメディアのpplがお互いを知っているかどうかはわかりませんが、ユーザー「ブライアン」が誰であるかを知ることができれば、彼が使用しているブラウザを尋ねることができますか？ インクルード
理由は、バグが何であるかはわかりますが、ブラウザでトリガーできません（手動でのみですが、pplは敵対的ではないため、おそらくオンではありませんでした）
目的）
09:49 <webzwo0i>（したがって、おそらく2つのバグがあります。1つはサーバー側、もう1つはクライアント側です）

必要な情報は、データベースがutf8またはutf8mb4の場合です。
問題のあるチェンジセットを抽出しました。適用しない場合、タイムスライダーはこれらのリビジョンを回避しません。

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

上記からの更新と一緒にこれはあなたのパッドを再び再利用可能にするはずです

@ webzwo0i

ええ、ミュータントがあなたに話しかけているのに気づきました。 githubの問題についてもフォローアップすることにしました。 「ブライアン」が誰で、どのブラウザを使用しているかを追跡します。

したがって、ストアテーブルはかなり長い間utf8mb4です。 utf8でしたが、6月に別の問題が発生したため、utf8mb4に変換しました。具体的には2015年6月23日です。

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

ユーザー/ブラウザを見つける必要はありません。今すぐバグを再現できます。 ありがとうございました！

最新リリースを使用しているため、dbSettings内のsettings.jsonに「charset」：「utf8mb4」を挿入する必要があります。 これは、settings.json.templateにあります。 これが必要かどうかを確認できます

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

データベーステーブル自体が4バイトのutf8を格納できるが、サーバーがクライアント接続に4バイトのutf8を期待していない場合、クライアント（およびおそらく接続？）はutf8mb4を示す必要があります。
これは古いパッドを修復しません。 ただし、すべてのパッドを繰り返し処理し、bin / checkPad.jsを使用して、同様の問題が発生する可能性のあるパッドの数とパッドを把握できます。 状況によっては、上記のように非常に簡単に修復できます（一部の文字は壊れますが）。 壊れたパッドがたくさんある場合は、これを自動化するのが理にかなっているかもしれません。

人々が実際に書いているときにこれらの問題が見られない理由は、ほとんどのサイトがパフォーマンスのためにueberDBの内部キャッシュを使用しているためです。 この純粋なJavaScriptキャッシュは、Unicodeを完全に認識しています。 キャッシュがフラッシュされるか、etherpadが再起動されるとすぐに、データベースからエントリを取得する必要があります。

私はあなたが指示したようにパッドを修理しました。 連続した4つの疑問符がそのような方法でPADを破壊することを見つけるのは興味深いことです。 そして、破損しているチェンジセットは、パッドの先端に比べて非常に古いでしょう。 しかし、あなたの説明は理にかなっています、それをありがとう。

「charset」：「utf8mb4」で構成を更新しました。

ウィキメディアでphabricatorチケットをフォローしていますが、アカウントを持っていないので、ここに投稿します。

2番目に壊れたパッドは、次を使用して修復することもできます。

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

iirc、4バイトUTF8の1バイトは有効なUTF8ではないため、4つの疑問符が症状です。 （UTF8では、最初の127文字のみがシングルバイトとして表されます。マルチバイトUTF8は、おそらく0x7fを超えるバイトを使用します）。 したがって、4つの疑問符は、実際には1つの4バイトでエンコードされたUTF8文字列を表します。これは、基本的な多言語プレーン（おそらく絵文字:-D）の外側のコードポイントを表します。 Javascriptでは、これらのコードポイントは、2つの16ビット値であるUTF16のサロゲートペアを使用してエンコードされます。

checkRepの問題は、チェンジセットに文字だけでなく変更の長さも格納することです。 ただし、Javascriptのlength（）関数はサロゲートペアを2としてカウントするため、たとえば絵文字の長さは2です。mysqlがチェンジセットの文字列を疑問符にデコードすると、チェンジセットの表現は無効になります。

ユーザーが最初に入力したコードポイントがわからないため、2つの疑問符に置き換えることは、実際の解決策ではありません（ただし、値がueberDBのキャッシュにある限り、そこから取得できます）。

誰かが実際に4つの疑問符を使用すると間違った結果が生成されます（長さの値は4を示し、2つの疑問符に置き換えると、代わりにcheckRepエラーが発生します）。したがって、修復スクリプトを自動化する場合は、チェックする必要があります。変更を適用した後の文字列の長さが「追加された文字数」（変更セットの値）に準拠している場合。

誰かが実際に4つの疑問符を使用し、さらに絵文字などのコードポイントを使用した場合に問題を回避するには、疑問符を置き換えるドキュメント内の位置も追跡する必要があります。

また、すべてのcheckRep-errorが壊れたエンコーディングによって引き起こされるわけではないことにも注意してください

そしてもちろん、上記はうまくいきました。 驚くばかり！ あなたには感謝してもしきれません。 構成の修正が行われていれば、これが二度と起こらないことを願っています。

あなたがしているデバッグは手動で行われているのだろうかと思っていました。 チェンジセットとその長さを手動で1つずつ取得して比較するか、それを行うためのより自動化された方法がある場合。 とにかく自分のものを作れると思います。

<3 @ webzwo0iありがとうございます。

@ webzwo0i最近（ドラッグアンドドロップのために）要素のX

エラーは、単一の絵文字（例：🐼）で新しいパッドを作成し、etherpadを再起動することで簡単に再現できます。＃3340も参照してください。

更新：2019年4月の時点で、この単一の絵文字自体は、再起動した後でもパッドを壊しません。

すべてのパッドをチェックしたかったので、 checkAllPadsツールを追加しました（PR＃3342を参照）。

エラーは、単一の絵文字（たとえば、panda_face）で新しいパッドを作成し、etherpadを再起動することで簡単に再現できます。＃3340も参照してください。

上記とまったく同じように、これを再現することはできません。 例については、 https： //etherpad.wikimedia.org/p/ohmyを参照して

このエラーでもパッドが壊れました。 不思議なことに、 checkPad,jsは問題を検出せず、 repairPad.jsは修正せずに完了します。 どのリビジョンに問題があるかを判断する方法はありますか？

編集：ああ、私は正しい方向を示しているhttps://gist.github.com/marcelklehr/a78d293571e7f06e3cf9を見つけました。 これがetherpad自体に含まれる可能性はありますか？ たくさんのおかげで、今は無限に役に立ちました！ （ただし、リビジョン番号を表示するには、 console.logをconsole.errorに置き換える必要がありました。nodeJSの経験はまったくありませんが、実際にすべてのログを表示する別の方法を見つけることができませんでした。 ）

実際、「 ????を??置き換える」を行うこともここで役立ちました。 :)最後のチェンジセットは誰かが絵文字を挿入したようです（ $????で終わりました）。

しかし、なぜこれが「マイナーバグ」に分類されるのかわかりません。 このバグにより、パッドが完全に失われます（ /timeslider気付くまで、この場合は1週間かかり、それでも履歴が失われます）。

これを修正する可能性は低いので、自分自身を割り当てません。 FWIW、このバグはeasysyncライブラリの制限によるものと思われますが、これはutf-8のすべてをサポートしているわけではないと私は推測しています。 （UTF-8は、1文字を複数バイトとしてエンコードする場合があります。各バイトは、1文字であっても、JavaScriptの文字列の長さに追加されます。）

-気にしない-：D

FWIW、このバグはeasysyncライブラリの制限によるものと思われますが、これはutf-8のすべてをサポートしているわけではないと私は推測しています。 （UTF-8は、1文字を複数バイトとしてエンコードする場合があります。各バイトは、1文字であっても、JavaScriptの文字列の長さに追加されます。）

実際、パッドには常にウムラウト（äöü）があり、UTF-8でもマルチバイトです。 上記の内容に基づくと、問題は実際にはUTF-16に関するものだと思います。これは、当初の設計では、文字あたり正確に2バイト（実際にはコードポイント）であることが意図されていましたが、現在は2バイトを超えています。 16のコードポイントには、絵文字のように4バイトを必要とするものがあります。 そして今、 length()はコードポイントの数と一致しなくなり、すべてが混乱します。

それで、おそらくより良い修正は、代理ペア（4バイトのコードポイント）を完全に拒否することですか？ それは補助面からの文字でetherpadを使用することを不可能にするでしょう、しかしそれはとにかく壊れているようです？ そしてそれはDBを保護するはずです。 JSでをテストする

なぜこれが閉鎖されたのですか？ 私の知る限り、EtherpadはまだBMP外の文字を窒息させます。 最近、この方法で壊れたパッドを手動で修理する必要がありました。

2014年発行を開いたので、もう興味がなくなったので閉じました。

まあ、それはまだ他の人にとって未解決の問題なので、再開していただければ幸いです。

ありがとう！ :)

パッドを確実に壊す文字（シーケンス）の例はありますか？ これは私が推測するデバッグを容易にするでしょう。

Easysyncライブラリは、テキスト（およびその長さ）を「文字」の観点から記述しますが、10年前からの最小限の実行可能な製品でした。 今日では、おそらくNFCで正規化されたUTF-8コードポイントの観点から考える必要があります。

疑問に思っているのですが、ueberdb値を照合されたテキスト列ではなくバイナリブロブとして保存することで問題を解決できるでしょうか？

現在、有効ではないバイトシーケンスutf8mb4（マルチバイト文字の一部を含むチェンジセットを考えてください）をutf8mb4列に入れようとすると、考えられる結果は2つだけです。データベースが入力、またはクライアント（またはサーバー）は、前に無効な「文字」またはバイトを削除する（「？」に置き換える）必要があります。

バイナリblob列を使用することにより、データベースはバイトシーケンスが無効なutf8mb4であることを認識しなくなるため、文字の置換を回避できる可能性があります。 easysyncが私が理解しているようにエンコーディングにとらわれない場合、これは機能する可能性があります（2人のユーザーがマルチバイト文字ABとCDを同じ位置に同時に挿入せず、これらが個別のチェンジセットA、C、B、Dとして終わる場合に限ります-これでorder-、マージされた結果を無効にするutf8mb4）。

PS：🍰のような4バイトのUTF8文字を挿入すること自体は問題ではないことをテストしたばかりです（ただし、まだ再起動していません。これは説明かもしれません）。したがって、バグには同時実行性が必要であると思います（文字が単独では無効な2つ以上のチェンジセットに分割するか、クライアントがそのような文字の一部を削除するチェンジセットを発行する必要があります。

こんにちは、私たちは多くのパッドでもこの問題を経験しています。

私はすべてを試していますが、これを🍰に置き換えることはできません。再起動、さまざまなデータベースバックエンド（適切に構成されている）を試しました。

最新のコードベースで複製する手順を誰かが提供できますか？

🍰でバックスペースを押すと、アイテムが に置き換えられますが、これは明らかに厄介です。

私にとって、 replace(値,'????','??')は、これまで常に機能してきました。 しかし、数ヶ月は起こっていません。

動作するCheckPad Deltasの更新バージョンを含めました。この問題が発生したときに役立つかどうかを試してみることができれば、ありがたいです。

それでも基本的な問題は、Etherpadデータモデルが正規化されたUTF-8コードポイントではなく「文字」の観点から考えることだと思います。

コアライブラリを作り直さない限り、これが実際に解決されることはありません。 明らかに、どんな緩和策も役に立ちます。 私の意見では、100％正しいことが保証されている_簡単な_ソリューションはないと言っているだけです。

どれだけ多くのエディター（そして開発者に非常に人気のあるエディター）がEtherpadthoと同様の経験をしているのか驚かれることでしょう。 今日遊んで、私はいくつかのクレイジーな経験をしました。

動作するCheckPad Deltasの更新バージョンを含めました。この問題が発生したときに役立つかどうかを試してみることができれば、ありがたいです。

＃3717（14ae2ee95094）でマスターブランチにプルインされました。

こんにちは、パッドの1つで同様の問題が発生しています。
@JohnMcLear残念ながら、

@gndパブリックインスタンスはありますか？

padId / export / etherpad urlを押して、.etherpadファイルを取得できますか？

最新の開発を実行していますか？

データベースのバックエンドは何ですか？

たくさんの質問がありますので、できるだけ詳しく教えてください

@JohnMcLear
はい、そのパブリックインスタンス： https ：
残念ながら、.etherpadファイルを取得しようとすると502 BadGatewayエラーが発生します
nodejs 12.16.3-1nodesource1で最新の開発（git pull origin）を実行しており、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] [情報]コンソール-ディレクトリでスキン「no-skin」を使用しています：/ opt / etherpad / src / static / skins / no-skin
[2020-05-05 00：04：12.371] [情報]コンソール-セッションキーは/opt/etherpad/SESSIONKEY.txtからロードされました
[2020-05-05 00：04：12.541] [エラー]コンソール-テーブルがcharsetutf8で構成されていません-これにより、特定の文字がパッドに貼り付けられるとクラッシュする可能性があります
[2020-05-05 00：04：12.543] [情報]コンソール-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 ：

@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

設定ミスは2つあり、データベースは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] [情報]コンソール-ディレクトリでスキン「no-skin」を使用：/ opt / etherpad / src / static / skins / no-skin
[2020-05-05 13：17：43.464] [情報]コンソール-セッションキーは/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必要に応じて、テキストを取得するためにテストするスクリプトを作成できますか？

ここでは、出力をstdoutに変更したbin/extractPadData.jsで十分かもしれません。2分extractPadText.jsを作成します

@JohnMcLearそれは確かに非常に役立ちます）

抽出

node bin/extractPadData.js $padid使用する
次にcat $padid.db | grep \"text\" | grep revNum | tail -1

テキストはval.atext.textアイテムです。これをcliでjson解析できます。必要に応じて次に実行します。今のところ、これらのコマンドを実行して、$ padidをPadIDに置き換えてください。

構文解析

sudo apt-get install jq jqをインストールし、次にcat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.textテキストだけを表示します。

パッドテキストをテキストファイルに書き込むにはcat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text > $padid.txt

これでパッドテキストができました。これをテキストファイルに入れてインポ​​ートするか、setTextAPIなどを使用してください...

Lemmeは抽出が失敗するかどうかを知っているので、別のアプローチを検討します。

抽出は実行されていますが、かなり遅いです。 CareCicle.dbファイルでは、スクリプトがすでに20分間実行されている間に、revs ：80に最新の行が表示されます。 問題のパッドには12k以上のリビジョンがあります。

ああ、それはひどいです..私はそれが80の改訂の後にpadオブジェクトを構築することができないと思います..スクリプトが実行されるのに30秒かそこらしかかからないはずです。

最後の提案は、データベース全体をダンプして私に送信するという大きな提案です。そうすれば、必要なものを解析するためのスクリプトを書くことができます。 あるいは、ここでスクリプトを書いてみることができますが、そのように機能させるために前後することがあるかもしれません。

こんにちは@JohnMcLear 、スクリプトはついに終了しました。 なぜそんなに時間がかかったのか（約40時間）わかりません。 とにかく、それを調べると、ストアテーブルから100で割り切れる最高のリビジョンを選択し、そこからテキストを抽出することで、演習全体を実行できるように思えます。 将来的には手でこれを行う病気です:)あなたの助けをどうもありがとう

まさにその通りですが、データベースクエリを実行できると思い込んでいると、ユーザーから言われることが多いので、避けようとしています。 なぜそんなに時間がかかったのか知っていると思いますが、MySQL @ Etherpad 1.8.3を使用していますか？

gitの最新のマスターを使用しています（どのバージョンかわかりません）

MySQLを想定すると、今日パッチが適用される予定のバグは既知です。

はい、申し訳ありませんが、最新のMariaDB-10.3.22-MariaDB

@JohnMcLearこのチケットをスパムして申し訳ありませんが、あなたが言及したMySQLパッチに未解決の問題がありますか？ etherpadでのパフォーマンスの問題がそれによって解決されるかどうかを確認したいです。ありがとう

いいえ、修正するにはnpm [email protected]を実行して

ところで、追加のテキストを保存するための新しいロジックが含まれているので、これを閉じる必要がありますが、問題が発生した場合は、新しい問題を作成して、これを参照してください。 破損が検出されたときにパッドをリアルタイムで復元する自動ロジックを作成することを主な目的として、問題の個々の原因にケースバイケースで対処したいと思います。 腐敗は避けられないので、それは夢です。

これは最近これに到達した人々へのメッセージです（古いバージョンのetherpadからアップグレードする場合）。

今日、私はetherpadサービスを1.6.3から1.8.6にアップグレードしました（なんという変更!!!!!すべての開発者におめでとうございます）

1つのパッドに問題があり、チェッカー（checkPad、checkAllPadsなど）がそれを検出できませんでした（または、とにかくノードを正常に実行する方法がわかりません）。

私はsettings.jsonでcharsetがutf8mb4であることを確認しました（最後のバージョンは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を付けました）が、もっと明確にしたかったのです

ここでできることの1つは、チェックすることだと思いますか???? パッドの内容で、提案された解決策を含む警告を提供します。 @ pedro-nonfree checkPad.jsなどにパッチを送信していただければ、喜んでマージします:)