Ajout d’un point de données à ce sujet : nous observons ce qui semble être le même mécanisme sous-jacent, mais qui se manifeste différemment.
Observé sur : Discourse core + discourse-ai, LLM : GPT-5.1 via OpenAI (connexion API personnalisée, pas un modèle pré-enrichi).
Preuves de reproduction
Même message source (russe, ~2000 caractères, en-têtes/gras/listes à puces/liens),
traduit dans plusieurs locales via la traduction AI native :
- Polonais (pl) : la structure du markdown de l’image intégrée a été perdue — passant de
à un lien malformé manquant le préfixe!
et le séparateur|, avec le texte alternatif et les dimensions fusionnés en texte brut. Affiché comme un lien cliquable au lieu d’une
image intégrée. - Ukrainien (uk) : des séquences littérales
\n\napparaissent en texte brut tout au long
du message, à la place des sauts de paragraphe. Le markdown de l’image dans cette
même traduction était intact — donc la corruption n’est pas liée à un symptôme fixe,
elle varie selon les exécutions.
Contrairement à la troncature décrite ci-dessus, notre cas ne montre aucun contenu manquant —
le texte complet est présent, mais avec des séquences d’échappement / syntaxe markdown
corrompues plutôt qu’une sortie raccourcie. Fournisseur différent (OpenAI vs Google
ici), symptôme différent (corruption vs troncature), même racine suspectée :
StructuredOutput#read_buffered_property reprenant sur
BestEffortJsonParser#extract_key, qui ne déséchappe pas les séquences de chaînes JSON (\n reste littéral) et semble également mal gérer les caractères spéciaux
adjacents à la syntaxe markdown lorsque la repli se déclenche en cours de parsing.
Aucune erreur dans les logs Sidekiq ou Rails de notre côté non plus — même comportement d’échec silencieux.