Añado un dato más a esto: estamos viendo lo que parece ser el mismo mecanismo subyacente, pero manifestándose de forma diferente.
Observado en: Discourse core + discourse-ai, LLM: GPT-5.1 vía OpenAI (conexión de API personalizada, no un modelo sembrado).
Evidencia de reproducción
Mismo mensaje original (en ruso, ~2000 caracteres, encabezados/negrita/listas con viñetas/enlaces),
traducido a varios idiomas mediante traducción AI nativa:
- Polaco (pl): la estructura del markdown de la imagen incrustada se perdió — pasó de
a un enlace mal formado que carece del prefijo!
y del separador|, con el texto alternativo y las dimensiones unidos como texto plano. Se renderizó como un enlace clicable en lugar de una imagen incrustada. - Ucraniano (uk): las secuencias literales
\n\naparecen como texto plano en todo el mensaje, en lugar de los saltos de párrafo. El markdown de la imagen en esta misma traducción estaba intacto — por lo que la corrupción no está vinculada a un síntoma fijo, varía según la ejecución.
A diferencia del truncamiento descrito anteriormente, nuestro caso no muestra contenido faltante —
el texto completo está presente, pero con secuencias de escape / sintaxis de markdown corruptas en lugar de una salida acortada. Proveedor diferente (OpenAI vs Google aquí), síntoma diferente (corrupción vs truncamiento), misma raíz sospechada:
StructuredOutput#read_buffered_property cayendo en la función de respaldo
BestEffortJsonParser#extract_key, que no desescapa las secuencias de cadenas JSON (\n permanece literal) y parece manejar incorrectamente los caracteres especiales adyacentes a la sintaxis de markdown cuando se activa la función de respaldo durante el análisis.
Tampoco hay errores en los registros de Sidekiq o Rails en nuestro lado — el mismo comportamiento de fallo silencioso.