Etherpad-lite: Gérer gracieusement la connexion à la base de données indisponible
Décrivez le bogue
Lorsque la connexion de la base de données au stockage principal n'est pas disponible (testée avec postgres), le serveur continue de planter au lieu de signaler correctement les problèmes de connexion à la base de données.
Reproduire
Étapes pour reproduire le comportement :
- Arrêtez votre serveur de base de données (postgres)
- Démarrer l'etherpad
- Visitez une page qui a besoin de la connexion à la base de données (n'importe quel pad devrait, dans mon cas, également déclenché lors de la visualisation de
/admin/plugins - Voir l'erreur
Comportement prévisible
Repli gracieux pour afficher un message d'erreur frontal, mais continuez à fonctionner malgré ce manque de connectivité à la base de données.
Comportement réel
[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)
Contexte supplémentaire
Etherpad version
Version number: 1.8.6
Latest available version: 1.8.6
Git sha: 6a8563e
BenBE
Tous les 5 commentaires
+1 ceci.
https://github.com/ether/ueberDB pour notre abstraction de base de données d'ailleurs. Ce n'est pas seulement un problème de PG, cela affecte toutes les bases de données.
J'accepterais un PR, je ne sais pas où est le mieux pour le réparer, je suppose que ueberdb émettra probablement lorsque la base de données est perdue.
Vous ne voudriez probablement jamais transmettre un message au client, mais peut-être qu'une erreur générique au client, effacer l'erreur dans les journaux du backend et mettre le cache en mémoire jusqu'à ce que la base de données soit restaurée. Le problème est que le cache en mémoire jusqu'à ce que la base de données restaurée nécessite une nouvelle logique pour chaque connecteur de base de données, ce qui peut représenter un travail plus important que nous n'en avons le temps.
Il convient de noter qu'Etherpad est conçu pour mourir par erreur, nous essayons de ne pas garder les choses en vie mais en échouant. C'était une décision de conception précoce qui a plutôt bien porté ses fruits car elle nous a obligés à rendre Etherpad stable (ish). J'ai l'impression que si la base de données a disparu, il devrait être très clair qu'Etherpad échoue car une base de données a disparu.
JohnMcLear
le 12 nov. 2020
Je ne pense pas que ce soit un problème de connectivité. column <name> is of type jsonb but expression is of type text semble être une chose assez courante qui se produit lorsque le middleware configure les paramètres de requête de manière inattendue. La colonne est créée en tant que JSONB, mais lorsque le générateur de requêtes utilise quelque chose comme JSON.encode, le type est supposé être une chaîne et le paramètre est lié au type TEXT ou VARCHAR ("caractère variant" dans les messages d'erreur).
Apparemment, cela peut également être un problème lors du stockage de chaînes ou de tableaux au lieu d'objets les contenant ?
Exemple aléatoire trouvé via Google, non lié à ce projet : https://github.com/jeremydaly/data-api-client/issues/27#issuecomment -584701957
martok
le 12 nov. 2020
Oh, vérifiez les commits inversés. Il y a quelque temps, il y a eu un mauvais commit de pg qui était lié, je pense.
JohnMcLear
le 12 nov. 2020
Je viens de remarquer -- on dirait que nous avons la CREATE TABLE avec jsonb dedans, la version dans node_modules n'est déjà que text . FWIW, nous avons également ueberdb_insert_or_update() avec un argument de texte, il n'en reste aucun surchargé ...
Juste pour être sûr avant de le convertir, le texte est ce qu'il est censé être (pour l'instant) ?
martok
le 13 nov. 2020
Après conversion en texte, tout semble fonctionner :
ALTER TABLE storage ALTER COLUMN value TYPE text USING value::text;
Questions connexes
YSelfTool
·
5Commentaires
ziyaointl
·
9Commentaires
ljoets
·
9Commentaires
kernelfreak
·
9Commentaires
ddeenniiss
·
4Commentaires
Commentaire le plus utile
Oh, vérifiez les commits inversés. Il y a quelque temps, il y a eu un mauvais commit de pg qui était lié, je pense.