Etherpad-lite: Kesalahan Tidak Tertangkap: Pernyataan gagal: set perubahan tidak valid (checkRep gagal)

Coba cabang Develop terbaru dan beri tahu kami jika masih ada

Ini tidak sepele karena terjadi secara kebetulan di server prod dengan banyak pengguna dan saya tidak dapat mereproduksinya.
Saya hanya dapat menguji apakah pembalut yang rusak tetap rusak saat berkembang, jika itu membantu.

ya silahkan

Saya akan menyalin db ke dev minggu depan. Akan melaporkan secepat mungkin. Terima kasih atas responnya yang cepat.

Sayangnya pindah ke pengembangan belum memperbaiki bantalan yang rusak. Menariknya, server yang bergerak (ekspor / impor sql sederhana) telah "memperbaiki" salah satu pad. Ia bekerja di server baru (bahkan di 1.3.0) tetapi bantalan kerusakan lain tidak. Masih error yang sama.

Ini adalah bug yang sangat aneh dan pembalut tampaknya terkadang hanya "memperbaiki diri" bahkan di PROD dan tanpa perubahan apa pun dari kami.

Secara teori, masalah ini seharusnya tidak terjadi sama sekali karena data yang buruk seharusnya tidak pernah menemukan jalannya sekarang ..

Saya dapat membiarkan ini terbuka dan jika terjadi pada data baru kami dapat mencoba menyelesaikannya ..

Apa yang Anda maksud dengan "data baru"? Apakah saya perlu mengembangkan PROD dan mencoba mendapatkan pembalut baru yang rusak?

Hrm, itu berpotensi menyakitkan .. Mungkin tunggu 1.4 yang akan keluar dalam beberapa minggu maks.

Kami mungkin melakukan itu. Terima kasih banyak.

Saya juga punya masalah itu, dengan keacakan aneh yang sama. Saya memperbarui ke etherpad-lite 1.4 dan masih ada. URL untuk salah satu pad http://etherpad.usabilidoido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4

Saat ini saya sedang dalam proses peningkatan ke 1.4 dan mudah-mudahan akan menggunakan versi baru, jadi saya dapat memeriksa apakah ada cacat baru muncul di bantalan baru setelah menjalankan versi baru.

@usabilidoido Anda dapat memberi tahu pengguna Anda untuk mengekspor-impor pad. Anda dapat mengakses kontrol dengan menambahkan / timeslider ke url seperti ini: http://etherpad.usabilidoido.com.br : 8080 / p / 07318a9b2b5666637d870fc50656323620af4df4 / timeslider

Ekspor sebagai html dan kemudian impor ke pad baru.

Saya mengalami masalah ini di 1.4. Pada pad yang rusak, baris perintah menampilkan [WARN] client - Uncaught TypeError: Cannot read property 'length' of undefined saat browser menampilkan kesalahan Failed assertion .

Kiat topi ke @ Ra1d3n untuk solusi / timeslider. Senang melihat konten pad masih bisa diakses di sana.

Ini hanya firasat, tetapi jika Anda suka, coba dengan cabang percobaan try/client-init-remove-checkRep baru saja saya buat. (Ini umumnya hal yang berbahaya untuk dilakukan, tetapi patut dicoba, menurut saya.)

Saya telah meningkatkan semuanya menjadi 1.4. dan kemarin pembalut kami rusak lagi. Mungkin masih menjadi salah satu yang rusak sebelum pembaruan, tetapi saya tidak yakin. Saya akan terus mencari.

@marcelklehr Sayangnya, saya tidak dapat memindahkan server produksi ke versi _dangerous_. Dan saya tidak dapat mencerminkan permintaan ke server sekunder karena saya tidak memiliki sumber daya. : - /

Maaf, saya tidak jelas: Jangan menjalankan produksi try/client-init-remove-checkRep , tetapi coba akses pad yang rusak dengan etherpad yang berjalan di cabang itu.

Saya menghapus checkRep di cabang itu, karena saya curiga bahwa normalisasi mungkin tidak berfungsi dengan benar dalam beberapa kasus. Jadi, ketika bantalan yang rusak bekerja pada cabang itu tanpa masalah sama sekali, kita harus meninjau kembali metode ini.

@marcelklehr Saya baru saja melakukannya, dan sayangnya itu tidak membantu.

Proses:

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

Saya mengonfirmasi bahwa perubahan tersebut sebenarnya ada di sistem file. (komentar dan baris baru ada di sana) Kesalahan masih sama.

Saya mendapatkan kesalahan yang disebutkan @ericpedia , dan itu tidak terjadi pada pad selain yang rusak.

konsol di server:

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

Ketika saya mematikan server, pesan ditampilkan di klien, juga:

Saya mungkin dapat memberi Anda impor SQL dari pad yang rusak, tetapi Anda harus memberi tahu saya apa sebenarnya yang perlu Anda ekstrak dari database terlebih dahulu. :-)

Konten pad yang sebenarnya akan sangat membantu, jadi itu akan menjadi db key pad:<PADID> (http://etherpad.org/doc/v1.4.0/#index_pad_padid) dan mungkin beberapa revisi terakhir.

Saya pikir saya semakin dekat:

checkPad mengatakan:

$ 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

Berlaku tidak cocok di semua kasus berarti bahwa kumpulan perubahan yang dimaksud mengharapkan satu karakter kurang dari yang sebenarnya ada (jadi, satu karakter yang tidak terduga). Setelah memeriksa dump db, saya menemukan bahwa semua perubahan ini mengikuti revisi dengan teks yang dilampirkan padanya (tidak semua revisi menyertakan konten pad lengkap, tetapi hanya delta, namun, sering kali karena alasan kinerja konten lengkap terpasang).

Agaknya, ada sesuatu yang salah dengan properti meta ini baik saat menyimpan revisi atau saat membuat teks saat ini untuk klien pad baru.

Saya baru saja menulis ulang checkPad untuk menggunakan atext yang dihitung daripada yang di-cache dan pad lewat. Bahkan teks yang di-cache juga benar! Ini membuat saya berpikir ada bug dalam beberapa algoritma yang menghitung teks lengkap untuk client_vars!

Kerja bagus sejauh ini Marcel. Sepertinya Anda hampir menyelesaikan masalah ini.

Ah, ini bukan generator client_vars. Algoritme yang bertanggung jawab untuk membuat teks yang di-cache rusak.

@ Ra1d3n Sebagai perbaikan cepat, Anda dapat menghidupkan kembali pad yang rusak dengan menghapus properti meta atext dari semua revisi kunci (di mana revNo % 100 == 0 ). "Memasukkan kembali" semua catatan yang terkait dengan bantalan yang rusak telah dilaporkan sebagai perbaikan untuk masalah serupa sejak lama - sekarang kita tahu mengapa ini berhasil :)

@marcelklehr Akankah itu membuat EP membangun kembali pad dari revisi 0 saat dimuat? Saya kira saya tidak boleh seenaknya menghapus semua properti atext dari semua revisi lalu ... :-) Adakah harapan untuk skrip "regenerate Pad" yang membangun kembali revisi kunci dengan algoritma yang benar?

Saya telah membuat beberapa perubahan pada checkPad-script. Lihat di sini: # 1653
Tapi ini lebih merupakan peretasan kotor. Jika skrip saya akan menyelesaikan masalah ini, saya akan menulis skrip untuk memperbaiki bantalan

Keren, saya menantikannya. Saat ini kami hanya mendapatkan sekitar satu pembalut yang rusak dalam seminggu, jadi saya cenderung menunggu perbaikan yang tepat. :-) Terima kasih.

Ya, saya sedang memikirkan skrip.

Jadi, perbedaan antara teks yang dihitung dan yang di-cache menunjukkan bahwa: "концертов" entah bagaimana diubah menjadi "ко цертов". Dalam revisi lain, "з" diubah menjadi " " juga ...

Saya tidak yakin tentang apa ini. Karakter ini ada di BMP Unicode, afaik, jadi saya tidak tahu apa yang terjadi dengan mereka.

Mutasi pada pad @ Ra1d3n terjadi pada revisi kunci 4900, 11400, 12300 dan 13600 (setiap putaran ke-100 adalah putaran kunci, yang berarti itu akan menyimpan isi pad penuh). Selain itu, AttributedText yang disimpan dalam catatan pad juga rusak. Semua revisi penting lainnya baik-baik saja. (dianalisis dengan skrip ini )

Karakternya tampak sangat acak. Tidak ada yang menonjol, sungguh. Saya tidak melihat polanya.

Saya menduga ada yang tidak beres saat menyimpan AttributedText di database. Karena kadang-kadang pad pulih di antara revisi kunci yang rusak, saya menduga bahwa teks yang disimpan dalam memori bagus. Terkadang, ketika disimpan di db, entah bagaimana itu akan rusak. Jika penulis terus mengedit dokumen sampai revisi kunci berikutnya dibuat dan revisi itu tidak rusak, maka tidak ada yang akan melihat apa pun.
Namun, jika server dimatikan _before_ mengelola untuk berhasil menyimpan AText valid yang disimpan dalam memori ke database, pad akan rusak pada awal server berikutnya.

@marcelklehr Kami mengalami etherpad crash dan pulih beberapa kali karena plugin yang tidak dikodekan dengan baik, mungkinkah ini penyebabnya? Aneh, hanya ada satu surat yang selalu rusak.

Saya membuat skrip untuk memasukkan kembali semua nilai database pad. Pada pembalut saya yang rusak, skrip tidak berfungsi.
@ Ra1d3n Anda dapat mengunduh skripnya di sini: https://github.com/Gared/etherpad-lite/blob/pad-repair-script/bin/repairPad.js
Pastikan instance etherpad Anda tidak berjalan saat Anda menjalankan skrip ini.

@Gared Dari mana Anda mendapatkan nilai dalam skrip Anda? Saya sarankan untuk melepas garpu checkPad saya, menyesuaikannya untuk memasukkan nilai AttributedText yang dihitung ulang ke dalam database.

@ Ra1d3n Etherpad crash tidak mungkin menyebabkan korupsi data, menurut saya.

@marcelklehr Ini mungkin hanya membuat masalah lebih terlihat, karena nilai memori yang benar hilang untuk kami dalam kasus tersebut.

@marcelklehr Skrip ini adalah cabang dari skrip extractPadData. Nilai dan kunci dimuat dalam fungsi di atas. Ini semua adalah kunci pad.

Skrip repairPad.js dari @Gared sedang memperbaiki bantalan saya yang rusak. Adakah kemungkinan perbaikan ini dimasukkan ke dalam versi etherpad-lite berikutnya?

Tentu, kirimkan saja permintaan tarik atau tanyakan @Gared ke

Permintaan tarik terbuka # 2210

Etherpad saya berjalan pada 1.4.1 dan saya mendapat 3 kali masalah yang sama seperti yang dijelaskan di atas: pad tidak dapat memuat tetapi / timeslider berfungsi dengan baik.
2 di antaranya sekarang dijalankan ulang tanpa melakukan apa pun.
Pada pad ketiga, saya mencoba repairPad.js namun tidak berhasil. URL-nya adalah: +1: http://portail.univ-lille1.fr/etherpad/link.jsp?groupID=g.jfobkKVrkydeTwLY&padID=SES_Grp8_Macroeconomie (Anda harus mengklik "utilisez le pad avec l'invitexy" untuk mengakses bantalan itu sendiri.

Mungkin ada changeet dengan nilai normal yang tidak diperhitungkan oleh repairPad atau apakah ada rilis baru reparPad.js yang belum saya lihat di git?

Kami pikir kami memiliki perbaikan untuk ini sekarang. Silakan tarik kembangkan dan uji :) Terima kasih!

Halo, kami baru saja mengalami hal ini. Kami menjalankan 1.5.7, itu adalah versi rilis terakhir. Backend adalah database MySQL. Saya tidak memiliki indikasi tentang tindakan pengguna yang mungkin menyebabkan ini.

Pad yang dimaksud: https://etherpad.wikimedia.org/p/iOS-iteration-planning

Mendapatkan data pad melalui trik pengatur waktu berfungsi dengan baik. Namun pad tidak akan pernah memuat.

Semua yang ada di database bisa dibuang dan disediakan untuk debugging jika itu membantu.

hai, saya melakukan diskusi ini di pagi hari.
08:47 <webzwo0i> mutante: saya men-debug pad. Anda biasanya tidak boleh melakukan ini, tetapi jika Anda memiliki cadangan database (dan setelah melakukan ekspor / etherpad untuk memiliki cadangan
pad) Anda dapat mengubah tiga entri database dan pad akan berfungsi dengan baik lagi. tiga perintah mysql tersebut

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> dapatkah Anda memeriksa apakah database Anda menjalankan utf8mb4 charset atau utf8?
08:51 <webzwo0i> oha up tolong jangan terapkan perintah-mysql. mungkin saya agak terlalu cepat :-) perlu memeriksa sesuatu terlebih dahulu
09:08 <webzwo0i> mh tidak baik-baik saja, silakan uji ... alangkah baiknya mengetahui apakah Anda menjalankan rilis terbaru atau yang lain dan plugin mana yang telah Anda aktifkan
09:47 <webzwo0i> Saya tidak tahu apakah Anda ppl di wikimedia saling mengenal, tetapi jika Anda dapat mengetahui siapa pengguna "Brian", dapatkah Anda menanyakan browser yang dia gunakan? itu
alasannya adalah saya dapat melihat apa bugnya, tetapi saya tidak dapat memicunya di browser saya (hanya secara manual, tetapi karena Anda ppl tidak bermusuhan, itu mungkin tidak aktif
tujuan)
09:49 <webzwo0i> (jadi kami mungkin memiliki dua bug, satu sisi server dan satu sisi klien)

info yang saya butuhkan adalah jika database Anda utf8 atau utf8mb4
Saya telah mengekstrak set perubahan yang melanggar, pengatur waktu tidak akan bekerja di sekitar revisi ini jika Anda tidak juga menerapkannya

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

bersama dengan pembaruan dari atas, ini akan membuat pad Anda dapat digunakan kembali

@ webtoona

Ya, saya perhatikan bahwa mutante berbicara dengan Anda. Saya baru saja memutuskan untuk menindaklanjuti masalah github juga. Saya akan melacak siapa "Brian" dan browser apa yang mereka gunakan untuk Anda.

Jadi, tabel penyimpanan adalah utf8mb4 untuk beberapa waktu sekarang. Itu utf8 tetapi kami mengubahnya menjadi utf8mb4 karena serangkaian masalah yang berbeda pada bulan Juni. Khususnya pada 23 Jun 2015

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

tidak perlu mencari tahu pengguna / browser, saya dapat mereproduksi bug sekarang. Terima kasih!

Karena Anda menggunakan rilis terbaru, Anda perlu memasukkan "charset": "utf8mb4" ke dalam settings.json di dalam dbSettings. Ini sekarang ada di settings.json.template. Anda dapat memeriksa apakah ini perlu dengan

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

klien (dan mungkin koneksi?) harus menunjukkan utf8mb4, jika bukan tabel-database Anda sendiri yang mampu menyimpan 4 byte utf8 tetapi server tidak mengharapkan 4byte utf8 sebagai koneksi klien.
Ini tidak memperbaiki pembalut lama Anda. Namun Anda dapat mengulang semua pad Anda dan menggunakan bin / checkPad.js untuk mengetahui berapa banyak dan pad mana yang mungkin memiliki masalah serupa. Bergantung pada situasinya, perbaikan bisa sangat mudah (walaupun beberapa karakter akan rusak) seperti dalam kasus di atas. Jika ada banyak bantalan yang rusak, mungkin masuk akal untuk mengotomatiskan ini.

Alasan masalah ini tidak terlihat ketika orang benar-benar menulis adalah karena sebagian besar situs menggunakan cache internal ueberDB untuk kinerja. Cache javascript murni ini benar-benar mengetahui Unicode. Segera setelah cache dihapus atau etherpad di-restart, ia perlu mendapatkan entri dari database.

Saya telah memperbaiki pad seperti yang Anda instruksikan. Menarik untuk mengetahui bahwa 4 tanda tanya berturut-turut akan merusak PAD sedemikian rupa. Dan bahwa set perubahan yang merusak akan sangat tua dibandingkan dengan ujung bantalan. Tapi penjelasanmu masuk akal, terima kasih untuk itu.

Saya telah memperbarui konfigurasi dengan "charset": "utf8mb4" juga.

Saya mengikuti tiket phabricator di wikimedia tetapi tidak memiliki akun di sana jadi saya mempostingnya di sini.

Bantalan rusak kedua Anda juga bisa diperbaiki dengan menggunakan:

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 tanda tanya adalah gejala karena, iirc, byte tunggal dalam UTF8 empat-byte bukan UTF8 yang valid. (Dalam UTF8, hanya 127 karakter pertama yang direpresentasikan sebagai byte tunggal, UTF8 multibyte mungkin menggunakan byte di atas 0x7f). Jadi 4 tanda tanya sebenarnya mewakili satu string UTF8 yang dikodekan 4byte, yang mewakili titik kode di luar Basic Multilingual Plane (kemungkinan besar emoji :-D). Dalam Javascript, titik kode tersebut akan dikodekan menggunakan pasangan pengganti UTF16, yaitu 2 nilai 16-bit.

Masalah checkRep adalah bahwa dalam set perubahan kita tidak hanya menyimpan karakter tetapi juga panjang perubahan. Fungsi length () Javascript, bagaimanapun, menghitung pasangan pengganti sebagai 2, jadi misalnya emoji memiliki panjang 2. Ketika mysql men-decode string dari sebuah perubahan ke tanda tanya daripada representasi kita dari sebuah set perubahan tidak valid lagi.

Menggantinya dengan dua tanda tanya adalah peretasan bukan solusi nyata karena kami tidak tahu titik kode mana yang dimasukkan pengguna di tempat pertama (tetapi selama nilainya ada di cache ueberDB, kami dapat mengeluarkannya dari sana).

itu akan menghasilkan hasil yang salah jika seseorang benar-benar menggunakan empat tanda tanya (nilai panjang kita akan menunjukkan 4, jika kita menggantinya dengan 2 tanda tanya kita akan mendapatkan kesalahan checkRep sebagai gantinya) jadi jika kita akan mengotomatiskan skrip perbaikan kita perlu memeriksa jika panjang string setelah menerapkan perubahan kita sesuai dengan "berapa banyak karakter yang ditambahkan" -nilai dari set perubahan.

Untuk mengatasi masalah jika seseorang benar-benar menggunakan empat tanda tanya dan juga kode poin seperti emoji kita juga perlu melacak posisi di dalam dokumen tempat kita mengganti tanda tanya tersebut.

perhatikan juga bahwa tidak semua checkRep-error disebabkan oleh encoding yang rusak

Dan tentu saja hal di atas berhasil. LUAR BIASA! Saya tidak bisa cukup berterima kasih. Saya berharap dengan perbaikan konfigurasi di tempat ini tidak akan terjadi lagi.

Saya bertanya-tanya apakah debugging yang Anda lakukan secara manual btw. Mendapatkan dan membandingkan set perubahan dan panjangnya satu per satu secara manual atau jika Anda memiliki cara yang lebih otomatis untuk melakukan itu. Saya kira saya bisa membuatnya sendiri, hanya karena penasaran

<3 @ webzwo0i Thanks man, kamu luar biasa

@ webzwo0i Saya telah melakukan cukup banyak dengan mendapatkan perwakilan karakter dari koordinat X pada elemen akhir-akhir ini (untuk drag and drop) dan saya merasa saya akan mengalami masalah ini di mana karakter tertentu dibungkus dengan tidak benar . Akan menarik untuk mengujinya di beberapa titik

Kesalahan dapat dengan mudah direproduksi dengan membuat pad baru dengan satu emoji (misalnya 🐼) dan memulai ulang etherpad, lihat juga # 3340.

Pembaruan : Mulai April 2019, emoji tunggal ini sendiri tidak merusak pad, bahkan setelah dimulai ulang.

Saya ingin memeriksa semua pad, jadi saya menambahkan alat checkAllPads (lihat PR # 3342).

Kesalahan dapat dengan mudah direproduksi dengan membuat pad baru dengan satu emoji (misalnya panda_face) dan memulai ulang etherpad, lihat juga # 3340.

Saya tidak dapat mereproduksi ini, melakukan persis seperti yang dijelaskan di atas. Lihat https://etherpad.wikimedia.org/p/ohmy untuk contoh (ya, saya sudah memulai ulang etherpad beberapa kali)

Kami baru saja mengalami kerusakan pad dengan kesalahan ini juga. Anehnya, checkPad,js tidak menemukan masalah, dan repairPad.js berjalan sampai selesai tanpa memperbaikinya. Apakah ada cara untuk menentukan revisi mana yang salah?

EDIT: Ah, saya menemukan https://gist.github.com/marcelklehr/a78d293571e7f06e3cf9 yang mengarahkan saya ke arah yang benar. Adakah kemungkinan ini bisa dimasukkan ke dalam etherpad itu sendiri? Ini sangat membantu sekarang, terima kasih banyak! (Namun, saya harus mengganti console.log dengan console.error bahkan untuk melihat nomor revisi. Saya tidak memiliki pengalaman nodeJS sama sekali, tetapi saya tidak dapat menemukan cara lain untuk benar-benar melihat semua logging. )

Memang melakukan "ganti ???? dengan ?? " juga membantu di sini. :) Sepertinya perubahan terakhir adalah seseorang memasukkan emoji (diakhiri dengan $???? ).

Namun, saya tidak mengerti mengapa ini diklasifikasikan sebagai "bug minor". Bug ini menyebabkan hilangnya total pad (sampai seseorang memperhatikan /timeslider , yang memakan waktu seminggu dalam kasus kami, dan bahkan kemudian riwayat hilang).

Menugaskan diri saya sendiri, karena sepertinya saya tidak akan bisa memperbaikinya. FWIW, bug ini tampaknya disebabkan oleh batasan pustaka easysync, yang saya spekulasi tidak mendukung semua utf-8. (UTF-8 dapat menyandikan satu karakter sebagai beberapa byte, yang masing-masing menambah panjang string dalam javascript, meskipun itu hanya satu karakter.)

-- tidak apa-apa

FWIW, bug ini tampaknya disebabkan oleh batasan pustaka easysync, yang saya spekulasi tidak mendukung semua utf-8. (UTF-8 dapat menyandikan satu karakter sebagai beberapa byte, yang masing-masing menambah panjang string dalam javascript, meskipun itu hanya satu karakter.)

Sebenarnya kami memiliki umlaut (äöü) di pad kami sepanjang waktu, yang juga multi-byte dalam UTF-8. Berdasarkan apa yang telah dikatakan di atas, saya pikir masalahnya sebenarnya tentang UTF-16 - yang, pada awalnya dirancang, dimaksudkan untuk memiliki tepat 2 byte per karakter (titik kode, sungguh), tetapi sekarang kami memiliki lebih dari 2 ^ 16 titik kode ada beberapa yang membutuhkan 4 byte, seperti emoji. Dan sekarang length() tidak lagi cocok dengan jumlah titik kode, dan semuanya menjadi bingung.

Jadi mungkin perbaikan yang lebih baik adalah dengan langsung menolak pasangan pengganti (titik kode 4-byte)? Itu akan membuat tidak mungkin untuk menggunakan etherpad dengan karakter dari pesawat tambahan , tapi sepertinya itu rusak? Dan itu harus melindungi DB. Tampaknya ada cara untuk menguji pasangan pengganti di JS (tapi saya tidak memiliki pengalaman dalam JavaScript modern).

Mengapa ini ditutup? Sepengetahuan saya, Etherpad masih tersedak karakter di luar BMP. Saya baru-baru ini sekali lagi harus memperbaiki pembalut yang rusak secara manual dengan cara ini.

Saya menutupnya karena saya membuka Edisi 2014 dan tidak tertarik lagi.

Nah, ini masih menjadi masalah terbuka bagi orang lain, jadi saya akan menghargai jika Anda bisa membukanya kembali.

Terima kasih! :)

Adakah yang punya contoh untuk karakter (urutan) yang memecahkan pad dengan andal? Saya kira ini akan memfasilitasi debugging.

Pustaka Easysync mendeskripsikan teks (dan legth) dalam istilah "karakter", tetapi itu adalah produk minimum yang layak dari 10 tahun yang lalu. Saat ini kita mungkin harus berpikir dalam hal poin kode UTF-8 yang dinormalisasi NFC.

Hanya ingin tahu, mungkinkah kami dapat menyelesaikan masalah dengan menyimpan nilai ueberdb sebagai blob biner daripada dalam kolom teks yang disusun?

Saat ini, jika kita mencoba untuk menempatkan urutan byte yang tidak valid utf8mb4 (pikirkan: kumpulan perubahan yang berisi bagian dari karakter multibyte) ke dalam kolom utf8mb4 , hanya ada dua hasil yang mungkin: apakah database menolak masukan, atau klien (atau server) perlu menghapus (pikirkan: ganti dengan "?") "karakter" atau byte yang tidak valid sebelumnya.

Dengan menggunakan kolom blob biner, database tidak lagi memperdulikan urutan byte menjadi utf8mb4 yang tidak valid, jadi kami mungkin menghindari penggantian karakter. Jika easysync adalah pengkodean agnostik seperti yang saya mengerti, ini bisa berfungsi (selama dua pengguna tidak memasukkan karakter multibyte AB dan CD pada posisi yang sama secara bersamaan dan ini berakhir sebagai perubahan individual A, C, B, D - dalam hal ini order -, membuat hasil gabungan utf8mb4 tidak valid).

PS: Saya baru saja menguji bahwa memasukkan karakter UTF8 4-byte seperti 🍰 bukanlah masalah itu sendiri (meskipun: Saya belum memulai ulang, yang mungkin merupakan penjelasan), jadi saya berasumsi bug tersebut memerlukan konkurensi (mengarah ke karakter yang terpecah menjadi dua atau lebih kumpulan perubahan yang tidak valid sendiri) atau memerlukan klien yang mengeluarkan kumpulan perubahan yang menghapus bagian dari karakter tersebut.

Hai, kami juga mengalami masalah ini pada banyak pembalut.

Saya mencoba segalanya dan tidak bisa menggantinya dengan 🍰, saya mencoba memulai ulang, backend database yang berbeda (yang dikonfigurasi dengan benar) ..

Adakah yang bisa memberikan langkah untuk meniru dengan basis kode kami yang lebih modern?

Menekan backspace pada 🍰 tidak mengganti item dengan yang jelas-jelas menyebalkan.

Bagi saya, replace( value ,'????','??') selalu berhasil sejauh ini. Ini tidak terjadi selama beberapa bulan.

Saya menyertakan versi terbaru dari Check Pad Deltas yang berfungsi, jika orang dapat mencobanya untuk melihat apakah itu membantu ketika mengalami masalah ini, saya akan sangat menghargainya.

Saya masih berpikir masalah dasarnya adalah bahwa model data Etherpad berpikir dalam istilah "karakter" dan poin kode UTF-8 tidak dinormalisasi.

Kecuali kita mengerjakan ulang perpustakaan inti, ini tidak akan pernah benar-benar diselesaikan. Jelas, mitigasi apa pun berguna. Bilang saja tidak ada solusi _easy_ yang dijamin 100% benar menurut saya.

Anda akan terkejut betapa banyak editor (dan yang sangat populer di kalangan pengembang) yang memiliki pengalaman serupa dengan Etherpad. Bermain-main hari ini saya punya beberapa pengalaman gila.

Saya menyertakan versi terbaru dari Check Pad Deltas yang berfungsi, jika orang dapat mencobanya untuk melihat apakah itu membantu ketika mengalami masalah ini, saya akan sangat menghargainya.

Ditarik di cabang master dengan # 3717 (14ae2ee95094).

Hai, kami mengalami masalah serupa dengan salah satu Pad kami.
@JohnMcLear sayangnya versi terbaru checkPadDeltas tidak membantu: /

@gnd apakah Anda memiliki contoh publik?

Dapatkah Anda menekan url padId / export / etherpad dan mendapatkan file .etherpad?

Apakah Anda menjalankan pengembangan terbaru?

Apa backend database Anda?

Begitu banyak pertanyaan, harap berikan detail sebanyak mungkin

@Tokopedia
Ya, ini adalah contoh publik: https://pad.xpub.nl/p/CareCircle
Sayangnya saya mendapatkan error 502 Bad Gateway saat mencoba mendapatkan file .etherpad
Kami menjalankan develop terbaru (git pull origin) di nodejs 12.16.3-1nodesource1, dengan db backend menjadi 10.3.22-MariaDB-0 + deb10u1.

Saya tersedia hari ini untuk membantu Anda dengan segala jenis debugging yang mungkin ingin Anda lakukan. Saya sudah mencoba versi terakhir checkPadDeltas, namun versi ini hanya hang selama berjam-jam setelah mulai. Ini adalah satu-satunya keluaran yang diberikan:

Semua jalur relatif akan diinterpretasikan relatif terhadap direktori basis Etherpad yang teridentifikasi: / opt / etherpad
[2020-05-05 00: 04: 12.330] [DEBUG] AbsolutePaths - Jalur relatif "settings.json" dapat ditulis ulang menjadi "/opt/etherpad/settings.json"
[2020-05-05 00: 04: 12.346] [DEBUG] AbsolutePaths - Jalur relatif "credentials.json" dapat ditulis ulang menjadi "/opt/etherpad/credentials.json"
pengaturan dimuat dari: /opt/etherpad/settings.json
Tidak ada file kredensial yang ditemukan di /opt/etherpad/credentials.json. Mengabaikan.
[2020-05-05 00: 04: 12.369] Konsol [INFO] - Menggunakan skin "no-skin" di dir: / opt / etherpad / src / static / skins / no-skin
[2020-05-05 00: 04: 12.371] Konsol [INFO] - Kunci sesi dimuat dari: /opt/etherpad/SESSIONKEY.txt
[2020-05-05 00: 04: 12.541] Konsol [ERROR] - tabel tidak dikonfigurasi dengan charset utf8 - Ini dapat menyebabkan crash ketika karakter tertentu ditempelkan pada pad
[2020-05-05 00: 04: 12.543] Konsol [INFO] - RowDataPacket {character_set_name: 'utf8mb4'} utf8

Teman, kesalahan ada di log Anda!

[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

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

@Tokopedia
db kami memiliki

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

Sedangkan meja toko memiliki

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

Jadi haruskah saya mengonversi menggunakan
ALTER DATABASE etherpad_lite_db CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

?

@Tokopedia

Kesalahan konfigurasi ada dua, database menggunakan utf8 dan utf8_general_ci, tetapi juga di settings.json charset untuk database ditetapkan sebagai "utf8". Setelah memperbaiki semua itu ke utf8mb4 masih tidak membantu, dan pad yang dimaksud tidak dimuat, dan checkPadDeltas masih hang:

Semua jalur relatif akan diinterpretasikan relatif terhadap direktori basis Etherpad yang teridentifikasi: / opt / etherpad
[2020-05-05 13: 17: 43.443] [DEBUG] AbsolutePaths - Jalur relatif "settings.json" dapat ditulis ulang menjadi "/opt/etherpad/settings.json"
[2020-05-05 13: 17: 43.444] [DEBUG] AbsolutePaths - Jalur relatif "credentials.json" dapat ditulis ulang menjadi "/opt/etherpad/credentials.json"
pengaturan dimuat dari: /opt/etherpad/settings.json
Tidak ada file kredensial yang ditemukan di /opt/etherpad/credentials.json. Mengabaikan.
[2020-05-05 13: 17: 43.463] Konsol [INFO] - Menggunakan skin "no-skin" di dir: / opt / etherpad / src / static / skins / no-skin
[2020-05-05 13: 17: 43.464] Konsol [INFO] - Kunci sesi dimuat dari: /opt/etherpad/SESSIONKEY.txt

@gnd Ini masalah GiGo. Setelah Anda memasukkan sampah, itu tidak dapat diubah. Sekarang yang Anda tahu adalah masalah tidak akan muncul di masa depan!

@gnd Ini masalah GiGo. Setelah Anda memasukkan sampah, itu tidak dapat diubah. Sekarang yang Anda tahu adalah masalah tidak akan muncul di masa depan!

Tidakkah repairPad.js dapat memperbaiki bantalan yang rusak ini?

Oh hi @caugner - sayangnya tidak, repairPad.js umumnya payah dan tidak benar-benar berfungsi. https://github.com/ether/etherpad-lite/blob/develop/bin/repairPad.js#L48

Hal terbaik yang bisa saya sarankan adalah menarik teks / teks dari pad dan membawanya ke pad baru.

@gnd Saya dapat menulis skrip untuk Anda uji untuk mencoba dan mendapatkan teks jika Anda mau?

bin/extractPadData.js dengan perubahan ke output ke stdout mungkin cukup disini .. 2 menit saya akan membuat extractPadText.js

@JohnMcLear itu memang akan sangat membantu)

Mengekstrak

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

Teksnya adalah item val.atext.text , Anda dapat menguraikannya dengan json di cli .. Saya akan melakukannya selanjutnya jika Anda membutuhkannya .. Untuk saat ini lakukan perintah ini untuk memastikan Anda mengganti $ padid dengan PadID Anda

Parsing

sudo apt-get install jq untuk menginstal jq lalu cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text untuk melihat teks saja.

Untuk menulis teks Pad ke file teks cat $padid.db | grep \"text\" | grep revNum | tail -1 | jq .val.atext.text > $padid.txt

Sekarang Anda memiliki teks pad yang dapat Anda masukkan ke dalam file teks dan impor atau atau Anda setText API atau apa pun ...

Biar saya tahu jika ekstraksi gagal dan saya akan mempertimbangkan pendekatan lain.

Ekstraksi sedang berjalan, namun cukup lambat. Di file CareCicle.db saya melihat baris terbaru di revs: 80 , sedangkan script sudah berjalan selama 20m. Pad dalam pertanyaan memiliki lebih dari 12 ribu revisi ..

Ya ampun, itu menyebalkan .. Saya kira itu tidak dapat membangun objek pad setelah 80 revisi .. Seharusnya hanya membutuhkan 30 detik atau lebih untuk menjalankan skrip.

saran terakhir akan sangat bagus, untuk membuang seluruh db dan mengirimkannya kepada saya dan kemudian saya dapat menulis skrip untuk mengurai apa yang Anda butuhkan. Atau saya dapat mencoba menulis skrip di sini tetapi mungkin ada beberapa bolak-balik untuk membuatnya berfungsi seperti itu.

Hai @JohnMcLear , skrip akhirnya telah selesai. Saya tidak tahu mengapa butuh waktu lama (hampir 40 jam). Bagaimanapun, ketika melihat ke dalamnya, menurut saya, keseluruhan latihan dapat dilakukan dengan memilih revisi tertinggi yang dapat dibagi 100 dari tabel penyimpanan dan mengekstrak teks darinya? Di masa depan saya akan melakukan ini dengan tangan :) Terima kasih banyak atas bantuan Anda

Persis seperti ini, tetapi saya sering diberitahu oleh pengguna kami ketika saya membuat asumsi bahwa mereka dapat melakukan kueri database jadi saya mencoba menghindarinya. Saya rasa saya tahu mengapa butuh waktu lama btw, apakah Anda menggunakan MySQL @ Etherpad 1.8.3?

Saya menggunakan master terbaru dari git (tidak yakin versi mana)

Dengan asumsi MySQL itu bug yang diketahui bahwa kami akan memiliki lahan tambalan hari ini.

ya maaf, MariaDB terbaru - 10.3.22-MariaDB

@JohnMcLear Saya minta maaf karena telah

Tidak, lakukan saja npm install [email protected] untuk memperbaikinya

Btw logika baru untuk menyimpan atext tambahan di jadi ini harus ditutup tetapi jika orang mengalami masalah tolong buat masalah baru dan lihat yang ini. Saya ingin menangani masing-masing penyebab masalah kasus per kasus dengan tujuan utama membuat logika otomatis untuk memulihkan pad pada korupsi yang terdeteksi secara real time. Itulah impian karena korupsi tidak bisa dihindari.

Ini adalah pesan untuk orang-orang yang mendapatkan ini baru-baru ini (saat meningkatkan dari versi etherpad yang lebih lama).

Hari ini saya meningkatkan layanan etherpad dari 1.6.3 menjadi 1.8.6 (sungguh perubahan !!!!! selamat untuk semua pengembang)

Saya punya masalah dengan satu pad, checker (checkPad, checkAllPads, dll.) Gagal mendeteksinya (atau saya tidak tahu cara menjalankan node dengan baik).

Saya memverifikasi charset adalah utf8mb4 di settings.json saya (lihat versi terakhir di settings.json.template ).

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

untuk kasus https://pad.example.com/p/my-broken-pad saya lakukan:

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

dan berhasil lagi: tada:: unicorn:: sparkles:

solusi ini ada di atas (saya memberi +1 pada pesan sebelumnya dengan solusi untuk membantu menemukannya), tetapi saya ingin membuatnya lebih jelas

Saya kira satu hal yang bisa kita lakukan di sini adalah memeriksa ???? dalam isi pad dan berikan peringatan yang menyertakan solusi yang disarankan. @ pedro-nonfree, bisakah Anda mengirimkan tambalan ke checkPad.js atau semacamnya, saya akan dengan senang hati menggabungkannya :)