Etherpad-lite: Manejar correctamente la conexión a la base de datos no disponible

Creado en 12 nov. 2020  ·  5Comentarios  ·  Fuente: ether/etherpad-lite

Describe el error
Cuando la conexión de la base de datos al almacenamiento de backend no está disponible (probado con postgres), el servidor sigue fallando en lugar de informar correctamente los problemas de conexión de la base de datos.

Reproducir
Pasos para reproducir el comportamiento:

  1. Detenga su servidor de base de datos (postgres)
  2. Iniciar etherpad
  3. Visite alguna página que necesite la conexión a la base de datos (cualquier pad debería funcionar, en mi caso, también se activa al ver /admin/plugins
  4. Ver error

Comportamiento esperado
Elegante respaldo para mostrar algún mensaje de error de la interfaz, pero seguir ejecutándose a pesar de esta falta de conectividad con la base de datos.

Comportamiento real

[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)

Contexto adicional

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

Comentario más útil

Oh, mira las confirmaciones revertidas. Hubo una mala confirmación de pg hace un tiempo que estaba relacionada, creo.

picture JohnMcLear en 12 nov. 2020
👍2

Todos 5 comentarios

+1 esto.

https://github.com/ether/ueberDB para la abstracción de nuestra base de datos por cierto. Esto no es solo un problema de PG, afecta a todas las bases de datos.

Aceptaría un PR, no estoy seguro de dónde es mejor solucionarlo, supongo que probablemente ueberdb emitirá cuando se pierda db.

Probablemente nunca querrá enviar un mensaje al cliente, así que tal vez solo sea un error genérico para el cliente, borre el error en los registros de backend y el caché en la memoria hasta que se restaure la base de datos. El problema es que el caché en la memoria hasta que la base de datos restaurada requiera una nueva lógica para cada conector de base de datos, lo que puede ser un trabajo más grande del que tenemos tiempo.

Vale la pena señalar que Etherpad está diseñado para morir en caso de error, intentamos no mantener las cosas vivas sino fallando. Fue una decisión de diseño temprana que valió la pena, ya que nos obligó a hacer que Etherpad fuera estable (ish). Los scripts de inicio de Etherpad intentarán reiniciar Etherpad y restablecer la conectividad db, no me opongo a cómo hacemos las cosas, pero Siento que si la base de datos se ha ido, debería quedar muy claro que Etherpad está fallando porque una base de datos ha desaparecido.

JohnMcLear picture JohnMcLear en 12 nov. 2020
👍1

No creo que esto sea un problema de conectividad. column <name> is of type jsonb but expression is of type text parece ser algo bastante común que sucede cuando el middleware configura parámetros de consulta de formas inesperadas. La columna se crea como JSONB, pero cuando el generador de consultas usa algo como JSON.encode, se infiere que el tipo es una cadena y el parámetro se enlaza como tipo TEXT o VARCHAR ("carácter variable" en los mensajes de error).
Aparentemente, eso también puede ser un problema al almacenar cadenas o matrices en lugar de objetos que las contienen.

Ejemplo aleatorio encontrado a través de Google, no relacionado con este proyecto: https://github.com/jeremydaly/data-api-client/issues/27#issuecomment -584701957

martok picture martok en 12 nov. 2020
👍1

Oh, mira las confirmaciones revertidas. Hubo una mala confirmación de pg hace un tiempo que estaba relacionada, creo.

JohnMcLear picture JohnMcLear en 12 nov. 2020
👍2

Me acabo de dar cuenta, parece que tenemos CREATE TABLE con jsonb, la versión en node_modules es solo text ya. FWIW también tenemos ueberdb_insert_or_update() con argumento de texto, no queda uno sobrecargado ...

Solo para estar seguro antes de convertirlo, ¿el texto es lo que se supone que es (por ahora)?

martok picture martok en 13 nov. 2020
👍1

Después de la conversión a texto, todo parece funcionar:

ALTER TABLE storage ALTER COLUMN value TYPE text USING value::text;
BenBE picture BenBE en 13 nov. 2020
👍1
¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

JohnMcLear picture JohnMcLear  ·  9Comentarios
ddeenniiss picture ddeenniiss  ·  4Comentarios
Unifex picture Unifex  ·  5Comentarios
muxator picture muxator  ·  7Comentarios
aswen picture aswen  ·  7Comentarios