Etherpad-lite: Menangani koneksi database dengan anggun tidak tersedia

Dibuat pada 12 Nov 2020  ·  5Komentar  ·  Sumber: ether/etherpad-lite

Jelaskan bugnya
Ketika koneksi database ke penyimpanan backend tidak tersedia (diuji dengan postgres), server terus mogok alih-alih melaporkan masalah koneksi database dengan lancar.

Untuk Mereproduksi
Langkah-langkah untuk mereproduksi perilaku:

  1. Hentikan server basis data Anda (postgres)
  2. Mulai etherpad
  3. Kunjungi beberapa halaman yang memerlukan koneksi database (pad apa pun harus dilakukan, dalam kasus saya, juga dipicu saat melihat /admin/plugins
  4. Lihat kesalahan

Perilaku yang diharapkan
Pengunduran yang anggun untuk menampilkan beberapa pesan kesalahan frontend, tetapi tetap berjalan meskipun kurangnya konektivitas basis data ini.

Perilaku sebenarnya

[2020-11-12 22:13:05.858] [ERROR] console - error: column "value" is of type jsonb but expression is of type text
    at Parser.parseErrorMessage (/home/etherpad/etherpad-lite/src/node_modules/pg-protocol/dist/parser.js:278:15)
    at Parser.handlePacket (/home/etherpad/etherpad-lite/src/node_modules/pg-protocol/dist/parser.js:126:29)
    at Parser.parse (/home/etherpad/etherpad-lite/src/node_modules/pg-protocol/dist/parser.js:39:38)
    at Socket.stream.on (/home/etherpad/etherpad-lite/src/node_modules/pg-protocol/dist/index.js:8:42)
    at Socket.emit (events.js:198:13)
    at Socket.EventEmitter.emit (domain.js:448:20)
    at addChunk (_stream_readable.js:288:12)
    at readableAddChunk (_stream_readable.js:269:11)
    at Socket.Readable.push (_stream_readable.js:224:10)
    at TCP.onStreamRead [as onread] (internal/stream_base_commons.js:94:17)
[2020-11-12 22:13:05.858] [INFO] console - Stopping Etherpad...
[2020-11-12 22:13:05.876] [ERROR] console - TypeError: Cannot read property 'name' of null
    at Client._handleParseComplete (/home/etherpad/etherpad-lite/src/node_modules/pg/lib/client.js:358:26)
    at Connection.emit (events.js:198:13)
    at Connection.EventEmitter.emit (domain.js:448:20)
    at parse (/home/etherpad/etherpad-lite/src/node_modules/pg/lib/connection.js:109:12)
    at Parser.parse (/home/etherpad/etherpad-lite/src/node_modules/pg-protocol/dist/parser.js:40:17)
    at Socket.stream.on (/home/etherpad/etherpad-lite/src/node_modules/pg-protocol/dist/index.js:8:42)
    at Socket.emit (events.js:198:13)
    at Socket.EventEmitter.emit (domain.js:448:20)
    at addChunk (_stream_readable.js:288:12)
    at readableAddChunk (_stream_readable.js:269:11)

Konteks tambahan

Etherpad version
Version number: 1.8.6
Latest available version: 1.8.6
Git sha: 6a8563e
picture BenBE

Komentar yang paling membantu

Oh, periksa komit yang dikembalikan. Ada komit pg buruk beberapa waktu lalu yang terkait, saya pikir ..

picture JohnMcLear pada 12 Nov 2020
👍2

Semua 5 komentar

+1 ini.

https://github.com/ether/ueberDB untuk abstraksi basis data kami btw. Ini bukan hanya masalah PG, mempengaruhi semua DB.

Saya akan menerima PR, saya tidak yakin di mana cara terbaik untuk memperbaikinya, saya kira mungkin ada ueberdb yang dipancarkan ketika db hilang.

Anda mungkin tidak akan pernah ingin mengirim pesan ke klien, jadi mungkin hanya kesalahan umum untuk klien, menghapus kesalahan di log backend dan cache ke memori sampai database dipulihkan. Masalahnya adalah cache ke memori sampai database dipulihkan mungkin memerlukan logika baru untuk setiap konektor database yang mungkin merupakan pekerjaan yang lebih besar daripada yang kita punya waktu untuk..

Perlu dicatat bahwa Etherpad dirancang untuk mati karena kesalahan, kami mencoba untuk tidak membuat semuanya tetap hidup tetapi gagal. Itu adalah keputusan desain awal yang terbayar cukup baik karena memaksa kami untuk membuat Etherpad stabil (ish) .. Skrip startup Etherpad akan mencoba untuk me-restart Etherpad dan membangun kembali konektivitas db, saya tidak menentang bagaimana kami melakukan sesuatu tetapi Saya merasa jika database hilang, itu harus sangat jelas bahwa Etherpad gagal karena database telah hilang.

JohnMcLear picture JohnMcLear pada 12 Nov 2020
👍1

Saya tidak berpikir ini adalah masalah konektivitas. column <name> is of type jsonb but expression is of type text tampaknya menjadi hal yang agak umum yang terjadi ketika middleware mengatur parameter kueri dengan cara yang tidak terduga. Kolom dibuat sebagai JSONB, tetapi ketika pembuat kueri menggunakan sesuatu seperti JSON.encode, tipenya disimpulkan sebagai string dan parameternya diikat sebagai tipe TEXT atau VARCHAR ("karakter bervariasi" dalam pesan kesalahan).
Rupanya itu juga bisa menjadi masalah saat menyimpan string atau array alih-alih objek yang mengandungnya?

Contoh acak ditemukan melalui Google, tidak terkait dengan proyek ini: https://github.com/jeremydaly/data-api-client/issues/27#issuecomment -584701957

martok picture martok pada 12 Nov 2020
👍1

Oh, periksa komit yang dikembalikan. Ada komit pg buruk beberapa waktu lalu yang terkait, saya pikir ..

JohnMcLear picture JohnMcLear pada 12 Nov 2020
👍2

Saya baru menyadari -- sepertinya kami mendapatkan CREATE TABLE dengan jsonb di dalamnya, versi di node_modules baru text . FWIW kami juga memiliki ueberdb_insert_or_update() dengan argumen teks, tidak ada yang kelebihan beban...

Hanya untuk memastikan sebelum saya mengonversinya, teks seperti apa yang seharusnya (untuk saat ini)?

martok picture martok pada 13 Nov 2020
👍1

Setelah konversi ke teks, semuanya tampak berfungsi:

ALTER TABLE storage ALTER COLUMN value TYPE text USING value::text;
BenBE picture BenBE pada 13 Nov 2020
👍1
Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

kernelfreak picture kernelfreak  ·  9Komentar
alekso87 picture alekso87  ·  6Komentar
muxator picture muxator  ·  7Komentar
kpcyrd picture kpcyrd  ·  8Komentar
ziyaointl picture ziyaointl  ·  9Komentar