Etherpad-lite: Trate com facilidade a conexão do banco de dados indisponível

Criado em 12 nov. 2020  ·  5Comentários  ·  Fonte: ether/etherpad-lite

Descreva o bug
Quando a conexão do banco de dados com o armazenamento de backend não está disponível (testado com postgres), o servidor continua travando em vez de relatar problemas de conexão do banco de dados.

Reproduzir
Passos para reproduzir o comportamento:

  1. Pare seu servidor de banco de dados (postgres)
  2. Iniciar etherpad
  3. Visite alguma página que precise de conexão com o banco de dados (qualquer pad deve servir, no meu caso, também acionado ao visualizar /admin/plugins
  4. Ver erro

Comportamento esperado
Fallback elegante para exibir alguma mensagem de erro de front-end, mas continue em execução, apesar da falta de conectividade do banco de dados.

Comportamento 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

Comentários muito úteis

Oh, verifique os commits revertidos. Houve um mau commit de pg um tempo atrás que estava relacionado, eu acho ..

picture JohnMcLear em 12 nov. 2020
👍2

Todos 5 comentários

+1 isto.

https://github.com/ether/ueberDB para nossa abstração de banco de dados btw. Este não é apenas um problema do PG, afeta todos os bancos de dados.

Eu aceitaria um PR, não tenho certeza de onde é melhor consertar, acho que provavelmente o ueberdb emite quando o db é perdido.

Provavelmente, você nunca iria querer enviar uma mensagem para o cliente, embora talvez apenas um erro genérico para o cliente, limpe o erro nos logs de back-end e cache para a memória até que o banco de dados seja restaurado. para cada conector de banco de dados, que pode ser um trabalho maior do que temos tempo.

Vale a pena notar que o Etherpad é projetado para morrer em caso de erro, nós tentamos não manter as coisas vivas, mas falhando. Foi uma decisão inicial de design que valeu a pena, pois nos forçou a tornar o Etherpad estável (ish). Os scripts de inicialização do Etherpad tentarão reiniciar o Etherpad e restabelecer a conectividade db, não sou contra como fazemos as coisas, mas Eu sinto que se o banco de dados sumiu, deveria estar muito claro que o Etherpad está falhando porque um banco de dados sumiu.

JohnMcLear picture JohnMcLear em 12 nov. 2020
👍1

Não acho que seja um problema de conectividade. column <name> is of type jsonb but expression is of type text parece ser uma coisa bastante comum que acontece quando o middleware configura parâmetros de consulta de maneiras inesperadas. A coluna é criada como JSONB, mas quando o gerador de consulta usa algo como JSON.encode, o tipo é inferido como uma string e o parâmetro é vinculado ao tipo TEXT ou VARCHAR ("caractere variando" nas mensagens de erro).
Aparentemente, isso também pode ser um problema ao armazenar strings ou arrays em vez de objetos que os contenham.

Exemplo aleatório encontrado por meio do Google, não relacionado a este projeto: https://github.com/jeremydaly/data-api-client/issues/27#issuecomment -584701957

martok picture martok em 12 nov. 2020
👍1

Oh, verifique os commits revertidos. Houve um mau commit de pg um tempo atrás que estava relacionado, eu acho ..

JohnMcLear picture JohnMcLear em 12 nov. 2020
👍2

Acabei de notar - parece que temos CREATE TABLE com jsonb, a versão em node_modules já é text . FWIW também temos ueberdb_insert_or_update() com argumento de texto, não sobrando nenhum sobrecarregado ...

Só para ter certeza antes de convertê-lo, o texto é o que deveria ser (por enquanto)?

martok picture martok em 13 nov. 2020
👍1

Após a conversão para texto, tudo parece funcionar:

ALTER TABLE storage ALTER COLUMN value TYPE text USING value::text;
BenBE picture BenBE em 13 nov. 2020
👍1
Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

wbt picture wbt  ·  7Comentários
ddeenniiss picture ddeenniiss  ·  4Comentários
JohnMcLear picture JohnMcLear  ·  9Comentários
aswen picture aswen  ·  7Comentários
Pita picture Pita  ·  7Comentários