Etherpad-lite: خطأ غير معلوم: تأكيد فشل: مجموعة تغييرات غير صالحة (فشل checkRep)

تم إنشاؤها على ١٤ مارس ٢٠١٤  ·  94تعليقات  ·  مصدر: ether/etherpad-lite

مرحبا شباب. نحن نستخدم المستقر ولدينا مشكلة أن بعض الفوط تتوقف عن العمل بشكل عشوائي وتتسبب في حدوث خطأ غير مسبوق في وحدة التحكم.

Uncaught Error: Failed assertion: Invalid changeset (checkRep failed) 

مثال:

https://etherpad.tugraz.at/p/l3tsbet

عندما يحدث هذا ، فإن تراكب "التحميل" يمنع أي إجراء. من غير المحتمل أن تكون مشكلة في النسخ واللصق لأنها تحدث في بعض الأحيان للوسادات المكتوبة بخط اليد بالكامل.

الشيء المثير للاهتمام هو أن شريط الوقت (الذي يتم فتحه عن طريق إلحاق / شريط التمرير الزمني إلى عنوان url) يعمل دائمًا بدون مشاكل.

https://etherpad.tugraz.at/p/l3tsbet/timeslider

نقوم الآن بإصلاح الوسادات يدويًا عن طريق تصدير + الاستيراد باستخدام HTML (فقد جميع مجموعات التغييرات). اي فكرة ما هو الخطأ؟

Serious Bug Waiting on Testing

التعليق الأكثر فائدة

يا صاح ، الخطأ في سجلك!

[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

ال 94 كومينتر

جرب أحدث فرع Develop وأخبرنا إذا كان لا يزال يحدث

هذا ليس بالأمر التافه لأنه يحدث بالصدفة على خادم prod مع العديد من المستخدمين ولا يمكنني إعادة إنتاجه.
يمكنني فقط اختبار ما إذا كانت الوسادات المكسورة لا تزال مكسورة ، إذا كان ذلك يساعد.

نعم من فضلك

سأحصل على نسخة ديسيبل إلى ديف الأسبوع المقبل. سوف يقدم تقريرا في أقرب وقت ممكن. شكرا لك على الاستجابة السريعة.

لسوء الحظ ، التحرك للتطوير لم يصلح الضمادات التالفة. ومن المثير للاهتمام أن الخوادم المتحركة (تصدير / استيراد SQL بسيطة) قد "أصلحت" إحدى اللوحات. إنه يعمل على الخادم الجديد (حتى في 1.3.0) لكن منصات التلف الأخرى لا تعمل. لا يزال نفس الخطأ.

هذا خطأ غريب حقًا ويبدو أن الفوط في بعض الأحيان مجرد "إصلاح ذاتي" حتى على PROD وبدون أي تغيير على الإطلاق منا.

من الناحية النظرية ، لا ينبغي أن تحدث هذه المشكلة على الإطلاق لأن البيانات السيئة يجب ألا تجد طريقها الآن ..

يمكنني ترك هذا مفتوحًا وإذا حدث على بيانات جديدة يمكننا محاولة حلها ..

ماذا تقصد ب "البيانات الحديثة"؟ هل أحتاج إلى تطوير PROD ومحاولة الحصول على وسادات مكسورة جديدة؟

حسنًا ، من المحتمل أن يكون هذا مؤلمًا .. ربما انتظر 1.4 والذي من المفترض أن يخرج في غضون أسابيع قليلة كحد أقصى.

قد نفعل ذلك. شكرا جزيلا.

لدي أيضًا هذه المشكلة ، بنفس العشوائية الغريبة. لقد قمت بالتحديث إلى etherpad-lite 1.4 ولا يزال موجودًا. عنوان URL لأحد الفوط http://etherpad.usabilidoido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4

أنا الآن بصدد الترقية إلى 1.4 وآمل أن أبدأ العمل مع الإصدار الجديد ، حتى أتمكن من التحقق مما إذا كانت هناك عيوب جديدة تظهر في منصات جديدة بعد التشغيل على الإصدار الجديد.

usabilidoido يمكنك إخبار المستخدمين بتصدير الوسادة واستيرادها. يمكنك الوصول إلى عناصر التحكم عن طريق إضافة / timelider إلى عنوان 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 لحل / مخطط التسلسل الزمني. مسرور لرؤية محتوى الوسادة لا يزال متاحًا هناك.

هذا مجرد حدس ، ولكن إذا أردت ، فجرّب الفرع التجريبي 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'.

لقد أكدت أن التغيير موجود بالفعل في نظام الملفات. (يوجد تعليق وسطر جديد) الخطأ لا يزال كما هو.

asd

لقد تلقيت الخطأ الذي ذكرته 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' }

عندما أقتل الخادم ، تظهر الرسالة في العميل ، أيضًا:

asd

قد أكون قادرًا على تزويدك باستيراد SQL للوحة المكسورة ، لكنك ستحتاج إلى إخباري بما تحتاجه بالضبط لاستخراجه من قاعدة البيانات أولاً. :-)

سيكون محتوى اللوحة الفعلي مفيدًا جدًا ، لذلك سيكون مفتاح db 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

يعني تطبيق غير متطابق في جميع الحالات أن مجموعة التغييرات المعنية توقعت حرفًا واحدًا أقل من الموجود بالفعل (لذلك ، حرف واحد غير متوقع). بعد فحص تفريغ db ، اكتشفت أن كل هذه التغييرات تتبع مراجعة مع ملحق ملحق بها (لا تتضمن جميع المراجعات محتويات اللوحة الكاملة ، ولكن بدلاً من ذلك فقط دلتا ، ومع ذلك ، في كثير من الأحيان لأسباب تتعلق بالأداء المحتويات الكاملة مرفقة).

من المفترض أن شيئًا ما انحرف مع هذه الخاصية الوصفية إما عند تخزين المراجعة أو عند إنشاء النص الحالي لعميل لوح جديد.

لقد قمت للتو بإعادة كتابة checkPad لاستخدام النص المحسوب بدلاً من المخزن مؤقتًا وتمرير اللوحة. حتى atexts المخبأة صحيحة! هذا يجعلني أعتقد أن هناك خطأ في بعض الخوارزمية التي تحسب النص الكامل لـ client_vars!

عمل جيد مارسيل حتى الآن. يبدو أنك على وشك حل هذه المشكلة.

آه ، إنه ليس منشئ client_vars. الخوارزمية المسؤولة عن إنشاء النص المخبأ معطلة.

@ Ra1d3n كإصلاح سريع ، يمكنك إحياء الوسادات المكسورة عن طريق حذف الخاصية الوصفية atext من جميع المراجعات الرئيسية (حيث revNo % 100 == 0 ). تم الإبلاغ عن "إعادة إدخال" جميع السجلات المتعلقة بلوحة مكسورة كإصلاح لمشكلات مماثلة منذ وقت طويل - والآن نعرف سبب نجاحها :)

marcelklehr هل سيجعل ذلك EP

لقد أجريت بعض التغييرات على البرنامج النصي checkPad. انظر هنا: # 1653
لكن هذا هو أكثر من اختراق قذرة. إذا كان البرنامج النصي الخاص بي سيحل هذه المشكلة ، فسوف أكتب نصًا لإصلاح الوسادات

رائع ، أنا أتطلع إلى ذلك. في الوقت الحالي ، نحصل على وسادة مكسورة واحدة فقط في الأسبوع ، لذلك أنا أميل إلى انتظار الإصلاح المناسب. :-) شكر.

نعم ، كنت أفكر في سيناريو.

لذا ، فإن الفرق بين النص المحسوب والنسخة المخبأة يوضح أن: "концертов" تحولت بطريقة ما إلى "коо цертов" في مراجعة أخرى ، تم تحويل "з" إلى " " أيضًا ...

لست متأكدًا مما يدور حوله هذا. هذه الأحرف موجودة في Unicode BMP ، afaik ، لذلك لا أعرف ما حدث لهم.

تحدث الطفرات في لوحة @ Ra1d3n في المراجعات الرئيسية 4900 و 11400 و 12300 و 13600 (كل 100 دورة هي دورة رئيسية ، مما يعني أنها ستخزن محتويات اللوحة الكاملة مؤقتًا). أيضًا ، فإن AttributedText المخزنة في سجل اللوحة تالفة أيضًا. جميع المراجعات الرئيسية الأخرى جيدة. (تم التحليل باستخدام هذا البرنامج النصي )

يبدو أن الأحرف عشوائية بشكل غير رسمي. لا شيء يبرز ، حقًا. أنا لا أرى نمط.

أظن أن هناك خطأ ما يحدث عند تخزين AttributedText في قاعدة البيانات. نظرًا لأن اللوحة تتعافى أحيانًا بين مراجعات المفاتيح المعطلة ، فأنا أعتقد أن النص المخزن في الذاكرة جيد. في بعض الأحيان ، عندما يتم تخزينه في db ، فإنه يتلف بطريقة ما. إذا استمر المؤلفون في تحرير المستند حتى يتم إنشاء المراجعة الرئيسية التالية ولم يتم إتلاف هذه المراجعة ، فلن يلاحظ أحد أي شيء.
ومع ذلك ، إذا تم إيقاف تشغيل الخادم _ قبل_ إدارة حفظ 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؟

بالتأكيد فقط أرسل طلب سحب معه أو اسأل Gared إلى

تم فتح طلب السحب رقم 2210

تعمل لوحة etherpad الخاصة بي على 1.4.1 ولدي 3 أضعاف نفس المشكلة الموضحة أعلاه: اللوحة غير قادرة على التحميل ولكن / timelider يعمل بشكل جيد.
يتم الآن إعادة تشغيل 2 منهم دون فعل أي شيء.
على اللوحة الثالثة ، حاولت إصلاح Repad.js دون جدوى. عنوان url الخاص به هو: +1: http://portail.univ-lille1.fr/etherpad/link.jsp؟groupID=g.jfobkKVrkydeTwLY&padID=SES_Grp8_Macroeconomie (عليك النقر فوق "utilisez le pad avec l'invitexy" للوصول إلى وسادة النفس.

ربما هناك مجموعة تغييرات ذات قيمة غير عادية لم يتم أخذها في الحسبان بواسطة repairPad أو هل هناك أي إصدار جديد من reparPad.js لم أره على git؟

نعتقد أن لدينا إصلاحًا لهذا الآن. الرجاء سحب تطوير واختبار :) شكرا!

مرحباً ، لقد حدث هذا للتو. نقوم بتشغيل 1.5.7 ، وهذا هو آخر إصدار تم إصداره. الخلفية هي قاعدة بيانات MySQL. ليس لدي أي مؤشرات على إجراءات المستخدم التي ربما تسببت في ذلك.

الوسادة المعنية: https://etherpad.wikimedia.org/p/iOS-iteration-planning

يعمل الحصول على بيانات اللوحة عبر خدعة منظم الوقت بشكل جيد. لكن الوسادة لن يتم تحميلها أبدًا.

يمكن تفريغ أي شيء في قاعدة البيانات وتوفيره للتصحيح إذا كان ذلك مفيدًا.

مرحباً ، لقد أجريت هذه المناقشة في الصباح.
08:47 <webzwo0i> mutante: قمت بتصحيح أخطاء اللوحة. عادة لا يجب عليك القيام بذلك ، ولكن إذا كان لديك نسخة احتياطية من قاعدة البيانات (وبعد إجراء التصدير / etherpad ، يجب أن يكون لديك نسخة احتياطية من
the pad) يمكنك تغيير ثلاثة إدخالات لقاعدة البيانات ويجب أن تعمل اللوحة بشكل جيد مرة أخرى. أوامر 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 charset أو utf8؟
08:51 <webzwo0i> يا شكا من فضلك لا تطبق أوامر mysql. ربما كنت أصوم قليلاً :-) بحاجة إلى التحقق من شيء أولاً
09:08 <webzwo0i> mh nope يجب أن يكون جيدًا ، يرجى الاختبار ... سيكون من الجيد معرفة ما إذا كنت قد قمت بتشغيل أحدث إصدار أو أي شيء آخر وما هي المكونات الإضافية التي قمت بتمكينها
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 أيضًا. سأتعقب من هو "Brian" والمتصفح الذي يستخدمونه لك.

لذا ، فإن طاولة المتجر هي 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 للأداء. هذه ذاكرة التخزين المؤقت لجافا سكريبت الخالصة تدرك تمامًا 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";

علامات الاستفهام الأربعة هي العَرَض ، لأن iirc ، البايت الفردي في UTF8 رباعي البايت غير صالح لـ UTF8. (في UTF8 ، يتم تمثيل أول 127 حرفًا فقط كبايت واحد ، وربما يستخدم UTF8 متعدد البايتات أعلى من 0x7f). لذا فإن 4 علامات استفهام تمثل في الواقع سلسلة UTF8 مشفرة بحجم 4 بايت ، والتي تمثل نقطة رمز خارج المستوى الأساسي متعدد اللغات (على الأرجح رمز تعبيري :- D). في جافا سكريبت ، سيتم تشفير نقاط الشفرة هذه باستخدام أزواج بديلة لـ UTF16 ، وهي قيمتان من 16 بت.

تكمن مشكلة checkRep في أننا في مجموعات التغييرات لا نخزن الأحرف فحسب ، بل نخزن أيضًا طول التغيير. ومع ذلك ، فإن دالة length () لجافا سكريبت تحسب الأزواج البديلة كـ 2 ، لذلك ، على سبيل المثال ، يكون طول الرمز التعبيري 2. عندما يفك mysql سلسلة التغييرات إلى علامات استفهام من تمثيلنا لمجموعة التغييرات لم يعد صالحًا بعد الآن.

استبدالها بعلامتي استفهام هو اختراق وليس حلاً حقيقيًا لأنه ليس لدينا أي فكرة عن نقطة الرمز التي أدخلها المستخدم في المقام الأول (ولكن طالما كانت القيمة في ذاكرة التخزين المؤقت لـ ueberDB ، يمكننا إخراجها من هناك).

قد ينتج عن ذلك نتائج خاطئة إذا استخدم شخص ما بالفعل أربع علامات استفهام (تشير قيمة الطول الخاصة بنا إلى 4 ، إذا استبدلناها بعلامتي استفهام ، فسنحصل على خطأ checkRep في المقابل) لذا إذا أردنا أتمتة برنامج نصي للإصلاح ، فسنحتاج إلى التحقق إذا كان طول السلسلة بعد تطبيق التغيير يتوافق مع "عدد الأحرف المضافة" - قيمة مجموعة التغييرات.

للالتفاف حول المشكلة إذا استخدم شخص ما بالفعل أربع علامات استفهام ونقاط رمز إضافية مثل الرموز التعبيرية ، نحتاج أيضًا إلى تتبع الموضع داخل المستند حيث نستبدل علامات الاستفهام.

لاحظ أيضًا أنه ليس كل خطأ checkRep ناتج عن تشفير معطل

وبالطبع عمل ما سبق. رائع! لا أستطيع أن أشكركم بما فيه الكفاية. آمل أنه مع إصلاح التكوين في مكانه لن يحدث هذا مرة أخرى.

كنت أتساءل عما إذا كان التصحيح الذي تقوم به يتم يدويًا. الحصول على مجموعات التغييرات ومقارنتها وأطوالها واحدة تلو الأخرى يدويًا أو إذا كان لديك طريقة آلية للقيام بذلك. أفترض أنه يمكنني إنشاء واحدة خاصة بي على أي حال ، مجرد فضول

<3 @ webzwo0i شكرا يا رجل أنت رائع

@ webzwo0i لقد كنت أفعل قدرًا معقولاً من خلال الحصول على ممثل char من

يمكن تكرار الخطأ بسهولة عن طريق إنشاء لوحة جديدة برمز تعبيري واحد (على سبيل المثال 🐼) وإعادة تشغيل 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 الذي console.log بـ console.error حتى لرؤية أي أرقام مراجعة. ليس لدي خبرة في nodeJS على الإطلاق ، لكن لم أتمكن من اكتشاف طريقة أخرى لرؤية جميع عمليات التسجيل. )

في الواقع ، عمل "استبدال ???? بـ ?? " ساعد هنا أيضًا. :) يبدو أن آخر التغييرات كانت عبارة عن شخص يقوم بإدخال رمز تعبيري (انتهى بـ $???? ).

ومع ذلك ، لا أفهم سبب تصنيف هذا على أنه "خطأ بسيط". يؤدي هذا الخطأ إلى خسارة كاملة للوسادة (حتى يلاحظ شخص ما الشيء /timeslider ، والذي استغرق أسبوعًا في حالتنا ، وحتى يتم فقد السجل).

غير محدد بنفسي ، لأنه من غير المحتمل أن أحصل على إصلاح هذا. FWIW ، يبدو أن هذا الخطأ يرجع إلى وجود قيود على مكتبة easyysync ، والتي أتوقع أنها لا تدعم كل نظام utf-8. (قد يشفر UTF-8 حرفًا واحدًا على هيئة وحدات بايت متعددة ، والتي يضيف كل منها إلى طول سلسلة في جافا سكريبت ، على الرغم من أنها مجرد حرف واحد.)

-- لا تهتم

FWIW ، يبدو أن هذا الخطأ يرجع إلى وجود قيود على مكتبة easyysync ، والتي أتوقع أنها لا تدعم كل نظام utf-8. (قد يشفر UTF-8 حرفًا واحدًا على هيئة وحدات بايت متعددة ، والتي يضيف كل منها إلى طول سلسلة في جافا سكريبت ، على الرغم من أنها مجرد حرف واحد.)

في الواقع لدينا علامات تغيير في اللوح (äöü) في لوحاتنا طوال الوقت ، وهي أيضًا متعددة البايت في UTF-8. استنادًا إلى ما قيل أعلاه ، أعتقد أن المشكلة تتعلق فعليًا بـ UTF-16 - والذي ، عند تصميمه في الأصل ، كان من المفترض أن يحتوي على 2 بايت لكل حرف (نقطة تشفير ، حقًا) ، ولكن الآن لدينا أكثر من 2 ^ 16 نقطة رمز هناك بعضها يحتاج إلى 4 بايت ، مثل الرموز التعبيرية. والآن لم يعد length() يطابق عدد نقاط التشفير ، وأصبح كل شيء مرتبكًا.

لذلك ربما يكون الحل الأفضل هو رفض أي أزواج بديلة (نقاط كود 4 بايت)؟ سيجعل ذلك من المستحيل استخدام etherpad مع أحرف من المستوى الإضافي ، لكن من المحتمل أن يكون هذا معطلاً على أي حال على ما يبدو؟ ويجب أن تحمي قاعدة البيانات. يبدو أن هناك طرقًا لاختبار الأزواج البديلة في JS (لكن ليس لدي خبرة في JavaScript الحديث).

لماذا تم إغلاق هذا؟ على حد علمي ، لا يزال Etherpad يختنق بشخصيات خارج BMP. اضطررت مؤخرًا إلى إصلاح وسادة مكسورة بهذه الطريقة يدويًا.

أغلقته لأنني فتحت العدد 2014 ولم أعد مهتمًا به.

حسنًا ، لا تزال مشكلة مفتوحة للآخرين ، لذا سأكون ممتنًا لو أمكنك إعادة فتحها.

شكر! :)

هل لدى أي شخص أي مثال على حرف (تسلسل) يكسر لوحة بشكل موثوق؟ هذا من شأنه أن يسهل التصحيح على ما أعتقد.

تصف مكتبة Easysync النص (والأساطير) من حيث "الأحرف" ، ولكنه كان منتجًا قابلاً للتطبيق منذ 10 سنوات. في الوقت الحاضر ، ربما يجب أن نفكر في نقاط رمز UTF-8 المعيارية بواسطة NFC.

فقط أتساءل ، هل يمكننا حل المشكلة عن طريق تخزين قيم ueberdb كنقاط ثنائية بدلاً من عمود نص مرتب؟

حاليًا ، إذا حاولنا وضع تسلسل بايت غير صالح utf8mb4 (فكر: مجموعة تغييرات تحتوي على جزء من حرف متعدد البايت) في عمود utf8mb4 ، فهناك نتيجتان محتملتان فقط: إما أن ترفض قاعدة البيانات الإدخال ، أو العميل (أو الخادم) بحاجة إلى إزالة (فكر: استبدل بـ "؟") "الأحرف" غير الصالحة أو البايت من قبل.

باستخدام عمود ثنائي ثنائي الأبعاد ، لن تهتم قاعدة البيانات بعد الآن بأن يكون تسلسل البايت utf8mb4 غير صالح ، لذلك قد نتجنب استبدال الأحرف. إذا كان easyysync محايدًا في الترميز كما أفهم ، فقد ينجح هذا (طالما لم يقم مستخدمان بإدخال أحرف متعددة البايت AB و CD في نفس الموضع في نفس الوقت وينتهي بهما الأمر كمجموعة تغييرات فردية A و C و B و D - في هذا الطلب - ، جعل النتيجة المدمجة utf8mb4 غير صالحة).

ملاحظة: لقد اختبرت للتو أن إدخال حرف UTF8 مكون من 4 بايت مثل not ليس مشكلة بحد ذاتها (على الرغم من: لم أقم بإعادة التشغيل بعد ، وهو ما قد يكون تفسيرًا) ، لذلك أفترض أن الخطأ إما يتطلب التزامن (مما يؤدي إلى وجود الشخصية تنقسم إلى مجموعتين أو أكثر من التغييرات غير الصالحة من تلقاء نفسها) أو تتطلب من العميل إصدار مجموعة تغييرات تزيل جزءًا من هذه الشخصية.

مرحبًا ، نحن أيضًا نواجه هذه المشكلة على الكثير من الفوط.

أحاول كل شيء ولا يمكنني استبدال هذا بـ ، لقد حاولت إعادة التشغيل ، خلفيات قاعدة بيانات مختلفة (تم تكوينها بشكل صحيح) ..

هل يمكن لأي شخص تقديم خطوات للتكرار باستخدام قاعدة الكود الأكثر حداثة لدينا؟

يؤدي الضغط على زر backspace على إلى استبدال العنصر بـ `` الذي من الواضح أنه ممتع.

بالنسبة لي ، تعمل replace( ,'????','??') دائمًا حتى الآن. لم يحدث لبضعة أشهر رغم ذلك.

لقد قمت بتضمين إصدار محدث من Check Pad Deltas يعمل ، إذا كان بإمكان الأشخاص تجربة ذلك لمعرفة ما إذا كان ذلك مفيدًا عند مواجهة هذه المشكلة ، فسأقدر ذلك.

ما زلت أعتقد أن المشكلة الأساسية هي أن نموذج بيانات Etherpad يفكر من حيث "الأحرف" وليس نقاط رمز UTF-8 الطبيعية.

ما لم نعد صياغة المكتبة الأساسية ، فلن يتم حل هذا حقًا. من الواضح أن أي تخفيف هو أمر مفيد. فقط أقول أنه لا توجد حلول سهلة مضمونة بنسبة 100٪ في رأيي.

ستندهش من عدد المحررين (والمحررين المشهورين جدًا لدى المطورين) الذين يتمتعون بتجربة مماثلة لـ Etherpad tho. أثناء اللعب اليوم كان لدي بعض التجارب المجنونة.

لقد قمت بتضمين إصدار محدث من Check Pad Deltas يعمل ، إذا كان بإمكان الأشخاص تجربة ذلك لمعرفة ما إذا كان ذلك مفيدًا عند مواجهة هذه المشكلة ، فسأقدر ذلك.

تم السحب في الفرع الرئيسي بالرقم 3717 (14ae2ee95094).

مرحبًا ، لدينا مشكلة مماثلة مع إحدى الفوط الصحية لدينا.
JohnMcLear للأسف أحدث إصدار من checkPadDeltas لم يساعد: /

gnd هل لديك مثيل عام؟

هل يمكنك الضغط على عنوان url الخاص بـ padId / export / etherpad والحصول على ملف .etherpad؟

هل تقوم بتشغيل أحدث تطوير؟

ما هي الخلفية لقاعدة البيانات الخاصة بك؟

أسئلة كثيرة جدًا ، يُرجى تقديم أكبر قدر ممكن من التفاصيل

تضمين التغريدة
نعم ، إنه مثيل عام: 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 المحددة dir: / 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 - يمكن إعادة كتابة المسار النسبي "أوراق الاعتماد. json" إلى "/opt/etherpad/credentials.json"
تم تحميل الإعدادات من: /opt/etherpad/settings.json
لم يتم العثور على ملف بيانات اعتماد في /opt/etherpad/credentials.json. تجاهل.
[2020-05-05 00: 04: 12.369] [INFO] وحدة التحكم - استخدام الجلد "no-skin" في dir: / 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] - لم يتم تكوين الجدول باستخدام charset 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

تضمين التغريدة
ديسيبل لدينا

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

؟

تضمين التغريدة

كان التهيئة الخاطئة ذات شقين ، كانت قاعدة البيانات تستخدم utf8 و utf8_general_ci ، ولكن أيضًا في settings.json تم تعيين أحرف قاعدة البيانات على أنها "utf8". بعد إصلاح ذلك كله على utf8mb4 لا يزال غير مفيد ، ولا يتم تحميل اللوحة المعنية ، ولا يزال checkPadDeltas معلقًا:

سيتم تفسير جميع المسارات النسبية بالنسبة إلى قاعدة Etherpad المحددة dir: / 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 - يمكن إعادة كتابة المسار النسبي "أوراق الاعتماد. json" إلى "/opt/etherpad/credentials.json"
تم تحميل الإعدادات من: /opt/etherpad/settings.json
لم يتم العثور على ملف بيانات اعتماد في /opt/etherpad/credentials.json. تجاهل.
[2020-05-05 13: 17: 43.463] وحدة تحكم [INFO] - استخدام الجلد "بدون جلد" في dir: / 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 من إصلاح هذه الوسادات المكسورة؟

Oh hicaugner - للأسف لا ، إن repairPad.js سيئة بشكل عام ولا تعمل حقًا. https://github.com/ether/etherpad-lite/blob/develop/bin/repairPad.js#L48

أفضل شيء يمكنني اقتراحه هو سحب النص / النص من اللوحة وإحضاره إلى لوحة جديدة.

gnd يمكنني أن أكتب لك نصًا لاختباره لمحاولة الحصول على النص إذا أردت؟

bin/extractPadData.js مع تغيير الإخراج إلى stdout قد يكون كافياً هنا .. دقيقتين سأقوم بإنشاء 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 لرؤية النص فقط.

لكتابة نص اللوحة في ملف نصي cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text > $padid.txt

الآن لديك نص اللوحة ، يمكنك فقط وضع ذلك في ملف نصي واستيراده أو تعيين واجهة برمجة تطبيقات النص أو أيًا كان ...

Lemme تعرف إذا فشل الاستخراج وسأفكر في طريقة أخرى.

الاستخراج قيد التشغيل ، ولكنه بطيء جدًا. أرى في الملف CareCicle.db أحدث سطر عند الدورات: 80 ، بينما يتم تشغيل النص بالفعل لمدة 20 مترًا. تحتوي اللوحة في الأسئلة على أكثر من 12 ألف مراجعة ..

يا رجل ، هذا مقرف .. أعتقد أنه لا يمكن إنشاء كائن pad بعد 80 مراجعة .. يجب أن يستغرق البرنامج 30 ثانية فقط أو نحو ذلك.

سيكون الاقتراح الأخير كبيرًا ، وهو التخلص من db بالكامل وإرساله إلي ، وبعد ذلك يمكنني كتابة برنامج نصي لتحليل ما تحتاجه. بدلاً من ذلك ، يمكنني محاولة كتابة نص برمجي هنا ، ولكن قد يكون هناك بعض الترجيع والإرسال لجعله يعمل بهذه الطريقة.

مرحبًا JohnMcLear ، انتهى النص أخيرًا. ليس لدي أي فكرة لماذا استغرق الأمر وقتًا طويلاً (حوالي 40 ساعة). على أي حال ، عند النظر في الأمر ، يبدو لي ، أنه يمكن إجراء التمرين بأكمله عن طريق اختيار أعلى مراجعة قابلة للقسمة على 100 من طاولة المتجر واستخراج النص منها؟ في المستقبل ، افعل هذا يدويًا :) شكرًا جزيلاً على مساعدتك

هذا بالضبط ، ولكن غالبًا ما يتم إخباري من قبل مستخدمينا عندما أفترض أنهم يستطيعون تنفيذ استعلامات قاعدة البيانات لذلك أحاول تجنبها. أعتقد أنني أعرف لماذا استغرق الأمر وقتًا طويلاً ، هل تستخدم MySQL @ Etherpad 1.8.3؟

أنا أستخدم أحدث إصدار من git (لست متأكدًا من الإصدار)

بافتراض أن MySQL خطأ معروف أنه من المقرر أن يكون لدينا تصحيح الأرض اليوم.

نعم آسف ، أحدث إصدار من MariaDB - 10.3.22-MariaDB

JohnMcLear أنا آسف

لا ولكن فقط قم بتثبيت npm [email protected] لإصلاحه

بالمناسبة ، فإن المنطق الجديد لتخزين نص إضافي موجود ، لذا يجب إغلاق هذا ولكن إذا واجه الأشخاص مشكلة ، فيرجى إنشاء مشكلة جديدة والرجوع إلى هذه المشكلة. أرغب في التعامل مع كل سبب فردي للمشكلة على حدة مع الهدف الرئيسي لإنشاء منطق آلي لاستعادة لوحة عند اكتشاف الفساد في الوقت الفعلي. هذا هو الحلم حيث أن الفساد أمر لا مفر منه.

هذه رسالة للأشخاص الذين وصلوا إلى هذا مؤخرًا (عند الترقية من الإصدارات القديمة من etherpad).

لقد قمت اليوم بترقية خدمة etherpad من 1.6.3 إلى 1.8.6 (يا له من تغيير !!!!! تهانينا لجميع المطورين)

واجهت مشاكل مع لوحة واحدة ، فشلت أجهزة الداما (checkPad ، checkAllPads ، إلخ) في اكتشافها (أو لا أعرف كيفية تشغيل العقدة بشكل جيد ، على أي حال).

لقد تحققت من أن charset هو utf8mb4 في الإعدادات الخاصة بي. 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"

ونجحت مرة أخرى: تادا:: يونيكورن:: بريق:

كان هذا الحل أعلاه (أضع +1 على الرسائل السابقة مع الحل للمساعدة في العثور عليه) ، لكنني أردت توضيحه بشكل أكثر

أعتقد أن شيئًا واحدًا يمكننا القيام به هنا هو التحقق من ؟؟؟؟ في محتويات الوسادة وتقديم تحذير يتضمن حلاً مقترحًا. @ pedro-nonfree ، رجاءً ، هل يمكنك إرسال تصحيح إلى checkPad.js أو شيء ما ، فسيسعدني دمج ذلك :)

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات