Problème d'encodage (coté MariaDB) pour les messages avec emoji dans Forgejo #26

New issue

Open

opened 2024-05-23 15:27:37 +00:00 by tixie · 1 comment

tixie commented

2024-05-23 15:27:37 +00:00

Owner

J'ai été confrontée à des erreurs 500 lorsque j'ai voulu poster un commentaire dans une issue.
Il se trouve que c'était parce que ce dernier contenait un émoji.

C'était quelque chose connu de @maximilien qui m'a aidé à cibler la source du problème rapidement sur Matrix.

Il a pu aussi partager l'erreur retournée :
gitea-server-1 | 1716409334 1716409334 0 false 0 0 0 none false] - Error 1366 (22007): Incorrect string value: '\xF0\x9F\x91\x8D J...' for column gitea.comment.content at row 1

N'y connaissant pas des masses je vais transmettre ses dires:

C'est un problème d'encodage coté MariaDB et une migration vers PostgresSQL le règlerait.
Idéalement tant qu'à faire ça, autant migrer Forgejo de sa VM actuelle vers un conteneur Nomad ("dans le cluster Stolon").

Faute d'être en mesure de savoir faire ça je créer cette issue comme point de départ et m'engage à mettre à jour le contenu de ce post avec la feuille de route si il y en a une qui se créer.
Je laisse le soin à @maximilien donc de ping les personnes que ça pourrait concerner. Un grand merci à lui en tout cas !

So far l'issue est pas très complète sur ce qu'il faudrait faire, et dans l'absolu le problème ne me semble pas urgent à traiter. Mais l'issue aura le mérite d'exister plutôt que le sujet soit perdu dans les logs Matrix.

J'ai été confrontée à des erreurs 500 lorsque j'ai voulu poster un commentaire dans une issue. Il se trouve que c'était parce que **ce dernier contenait un émoji**. C'était quelque chose connu de @maximilien qui m'a aidé à cibler la source du problème rapidement [sur Matrix](https://matrix.to/#/!QriWpyFqxZMEqVyClN:deuxfleurs.fr/$dmk7CaFdgPWerZN4mVfX_MS8M8vm67pdQ14Umo4uZzc?via=zinz.dev&via=matrix.org&via=deuxfleurs.fr). Il a pu aussi partager l'erreur retournée : `gitea-server-1 | 1716409334 1716409334 0 false 0 0 0 none false] - Error 1366 (22007): Incorrect string value: '\xF0\x9F\x91\x8D J...' for column gitea.comment.content at row 1` N'y connaissant pas des masses je vais transmettre [ses dires](https://matrix.to/#/!QriWpyFqxZMEqVyClN:deuxfleurs.fr/$XKVrnGXKRu_vNmnVc19WCgJ8vMqrgFF6EMQACFQC9gU?via=zinz.dev&via=matrix.org&via=deuxfleurs.fr): 1. C'est un problème d'encodage coté MariaDB et une migration vers PostgresSQL le règlerait. 2. Idéalement tant qu'à faire ça, autant migrer Forgejo de sa VM actuelle vers un conteneur Nomad ("dans le cluster Stolon"). Faute d'être en mesure de savoir faire ça je créer cette issue comme point de départ et m'engage à mettre à jour le contenu de ce post avec la feuille de route si il y en a une qui se créer. Je laisse le soin à @maximilien donc de ping les personnes que ça pourrait concerner. Un grand merci à lui en tout cas ! So far l'issue est pas très complète sur ce qu'il faudrait faire, et dans l'absolu le problème ne me semble pas urgent à traiter. Mais l'issue aura le mérite d'exister plutôt que le sujet soit perdu dans les logs Matrix.

tixie changed title from ~~Problème d'encodage (coté MariaDB) pour les commentaires ave emoji dans Forgejo~~ to Problème d'encodage (coté MariaDB) pour les messages avec emoji dans Forgejo

2024-05-23 15:28:00 +00:00

maximilien commented

2024-05-24 06:01:15 +00:00

Owner

Beaucoup de merci pour avoir créer le ticket. Quelques informations sur la situations :

Forgejo (feu Gitea) a été provisionné sur une VM chez moi (sur du matériel perso) et non sur un cluster car nous n'étions pas sûr de la manière de gérer ça dans nomad à l'époque
La grande question était comment faire une sauvegarde consistante de la base de dépôt git, qui sont juste des fichiers plats dans un dossier
Actuellement le disque entier de la VM est sauvegardé avec un snapshot au niveau bloc qui assure la consistence entre la base de donnée et les fichiers stocké par git (merci ZFS)

Voilà ce qui a été plus ou moins décidé après de multiples réunions sur le sujet :

Bouger forgejo sur nomad
Mettre la base MySQL/MariaDB dans notre postgres centralisé, ou bien migrer vers une base SQLite avec litestream
Mettre en place un job de backup qui éteint forgejo le temps de copier les données des repo git
- Il me semble que @lx avait trouvé une API qui permettait de dump l'intégralité des repos, mais je n'arrive pas à remettre la main dessus
- La manière officielle de faire semble d’appeler la commande forgejo dump (voir doc) mais il est clairement précisé que cela doit être fait avec le serveur éteint pour éviter les risques de corruption de la donnée par écriture concurrente à la copie

Alternativement, il y a la possibilité d’amorcer une migration de notre système de fichier de base vers BTRFS ou ZFS, et utiliser un subvolume/databaset dédié pour les points de montage de donnée pour les conteneurs. Cela permettrait au job de backup de procéder à un snapshot du système de fichier et ensuite de monter ce snapshot quelque part pour la copie des éléments dans la cible de sauvegarde.

Beaucoup de merci pour avoir créer le ticket. Quelques informations sur la situations : - Forgejo (feu Gitea) a été provisionné sur une VM chez moi (sur du matériel perso) et non sur un cluster car nous n'étions pas sûr de la manière de gérer ça dans nomad à l'époque - La grande question était comment faire une sauvegarde consistante de la base de dépôt git, qui sont juste des fichiers plats dans un dossier - Actuellement le disque entier de la VM est sauvegardé avec un snapshot au niveau bloc qui assure la consistence entre la base de donnée et les fichiers stocké par git (merci ZFS) Voilà ce qui a été plus ou moins décidé après de multiples réunions sur le sujet : - Bouger forgejo sur nomad - Mettre la base MySQL/MariaDB dans notre postgres centralisé, ou bien migrer vers une base SQLite avec [litestream](https://litestream.io/) - Mettre en place un job de backup qui éteint forgejo le temps de copier les données des repo git - Il me semble que @lx avait trouvé une API qui permettait de dump l'intégralité des repos, mais je n'arrive pas à remettre la main dessus - La manière officielle de faire semble d’appeler la commande `forgejo dump` (voir [doc](https://forgejo.org/docs/latest/admin/upgrade/#backup)) mais il est clairement précisé que cela doit être fait avec le serveur éteint pour éviter les risques de corruption de la donnée par écriture concurrente à la copie Alternativement, il y a la possibilité d’amorcer une migration de notre système de fichier de base vers BTRFS ou ZFS, et utiliser un subvolume/databaset dédié pour les points de montage de donnée pour les conteneurs. Cela permettrait au job de backup de procéder à un snapshot du système de fichier et ensuite de monter ce snapshot quelque part pour la copie des éléments dans la cible de sauvegarde.

❤️ 1

No labels

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/nixcfg#26

No description provided.