Comment j'ai prouvé que mon propre rapport de bug était faux : débogage Telegram d'OpenClaw via le proxy apiRoot

Le paramètre apiRoot de Telegram pour chaque compte OpenClaw peut être pointé vers un proxy local pour capturer les charges utiles réelles, vous permettant de distinguer les vrais bugs de réinsertion des artefacts de rendu côté client. Un développeur a utilisé cela pour prouver que son propre rapport de bug était erroné — et l'a retiré.

La saga du rapport de bug

La semaine dernière, un agent principal a commencé à refuser des instructions, prétendant que les messages contenaient un bloc système injecté. L'utilisateur a déposé le problème n°137927. Il s'est avéré que le contexte d'exécution interne d'OpenClaw fuyait dans le texte visible des messages, ressemblant à une injection. Le problème a été fermé après la fusion de trois correctifs, mais les mainteneurs ont noté que ces correctifs ne résolvaient pas le symptôme de « bloc complet réinséré dans un texte propre » signalé par l'utilisateur. Six problèmes frères restaient ouverts.

Pourquoi les preuves étaient faibles

Lorsque l'utilisateur a retesté en supprimant le HTML et en copiant le texte propre, les délimiteurs sont réapparus. Un commentateur a souligné que cela pouvait être dû à quatre choses différentes : écho du modèle, contamination par rejeu, rendu côté client, ou réinsertion réelle par le canal. Les preuves de l'utilisateur — du texte collé depuis un client de chat — ne pouvaient pas distinguer ces cas. Personne dans les onze fils de discussion n'avait capturé la charge utile réellement transmise.

Capturer la charge utile filaire

La configuration Telegram d'OpenClaw a un apiRoot par compte. Le pointer vers un proxy de journalisation local fait passer les appels API de ce compte par le proxy au lieu de Telegram. Étapes :

• Créez un bot jetable via BotFather.
• Ajoutez-le comme deuxième compte Telegram dans la configuration, lié au même agent.
• Définissez uniquement le apiRoot de ce compte vers un proxy de journalisation local.
• Le proxy journalise le corps de la requête, la transmet à api.telegram.org, et renvoie la réponse.
• Les comptes de production conservent de vrais jetons et le apiRoot par défaut — rien d'autre ne transite par ce proxy.

Environ 120 lignes de Python de la bibliothèque standard suffisent pour le proxy.

Les résultats

Test un : Prose simple sans délimiteurs. La charge utile filaire était complètement propre. Mais la réponse de l'agent mentionnait que son entrée était arrivée avec le bloc de contexte complet ajouté — donc le bloc atteint le modèle même lorsque la sortie est propre.

Test deux : L'utilisateur a envoyé le texte d'en-tête dépouillé. La charge utile filaire montrait <<<BEGIN_OPENCLAW_INTERNAL_CONTEXT>>> (échappé HTML), mais ce qui était copié était le littéral <<<BEGIN\_OPENCLAW\_INTERNAL\_CONTEXT>>>. Le délimiteur littéral n'a jamais été transmis — l'agent l'a cité en décrivant le bloc, OpenClaw l'a échappé HTML (parse_mode est HTML), Telegram l'a rendu à la chaîne littérale, et la copie a donné la version non échappée.

La conclusion

Toute transcription collée dans un rapport de bug a déjà subi un rendu et une copie — elle ne peut pas prouver la transmission par rapport à la citation. Plusieurs rapports reposent sur de telles preuves faibles. Cette méthode de débogage s'avère plus fiable. De plus, en lisant les correctifs, l'utilisateur a trouvé quelque chose de pire — un problème architectural distinct — qu'il prévoit de signaler séparément.