El bug que no existe: Gorgias y el error que nadie sabe reproducir

Un usuario avisa de que el formulario no le envió nada. En el panel no hay error, ni traza, ni fila nueva en la base de datos. Se prueba en tres navegadores y funciona las tres veces. El ticket se cierra con la frase que cierra la mitad de los tickets del mundo: no se reproduce.

Dos semanas después vuelve a pasar. Y otra vez no hay nada que mirar.

El hombre que demostró que nada existe

Gorgias de Leontinos, sofista y contemporáneo de Sócrates, escribió el tratado con el título más provocador de la Antigüedad: Sobre el no-ser. Defendía tres tesis encadenadas:

1. Nada existe.
2. Si algo existiera, no podríamos conocerlo.
3. Si pudiéramos conocerlo, no podríamos comunicárselo a nadie.

Suele leerse como una broma de gremio: la demostración de que con suficiente técnica se argumenta cualquier cosa. Pero funciona mejor como diagnóstico que como broma, porque describe con exactitud las tres paredes contra las que choca un fallo intermitente. Un bug de verdad las recorre en orden, y en cada una hay alguien dispuesto a cerrarlo.

Primera tesis: no existe

“No se reproduce” no significa “no ocurre”. Es un enunciado sobre el observador, no sobre el sistema: describe lo que no ha conseguido ver quien lo escribe.

La asimetría de la prueba es incómoda. Quien no logra reproducirlo no ha refutado nada; ha fallado en reproducirlo, que es otra cosa. Quien lo sufrió tiene la única evidencia disponible, aunque venga sin stack trace: le pasó.

Los intermitentes viven donde el entorno de desarrollo no llega. Una sesión que caduca a mitad de formulario. Una latencia que solo aparece con datos reales. Dos pestañas abiertas. Un móvil con la batería en modo ahorro que congela el temporizador. Una condición de carrera que necesita dos personas haciendo clic con un segundo de diferencia, algo que nunca pasa cuando el que prueba es uno solo.

Reproducir es un lujo. Cuando lo tienes, el bug ya está medio arreglado; lo difícil es todo lo anterior.

Segunda tesis: existe, pero no se puede conocer

Aquí el sistema deja de ser cómplice y pasa a ser mudo. No se puede conocer lo que no se instrumentó: la aplicación solo sabe lo que le pediste que recordara, y ese acuerdo se firmó meses antes de que apareciera el fallo.

Un log que dice error al guardar no es conocimiento. Es ruido con formato. Conocimiento sería qué entrada llegó, qué usuario, qué versión del cliente, a qué hora y por qué rama del código pasó. Sin identificador que hile los eventos de una misma petición, lo que queda no es una historia: son tres historias troceadas y mezcladas, y cualquiera puede leer en ellas lo que ya sospechaba.

Lo caro nunca es añadir trazas. Lo caro es descubrir, en mitad del incidente, cuáles hacían falta.

La regla: si un fallo no se reproduce, la primera tarea no es arreglarlo. Es hacerlo visible. Un parche a ciegas no cura nada, y encima cambia el escenario: pierdes la única pista que tenías y ya no sabrás si dejó de aparecer porque lo tocaste o porque hoy no tocaba.

Tercera tesis: se conoce, pero no se comunica

La tercera pared es la del lenguaje, y es la que más tiempo consume.

“No va.” “Se queda pillado.” “A veces no me deja.” El usuario no está siendo vago: está describiendo una experiencia, y una experiencia no es un hecho técnico. Su frase es honesta y a la vez inservible, igual que “me duele aquí” es verdad y no es un diagnóstico.

El puente son tres preguntas, y ninguna es técnica: qué esperabas que pasara, qué pasó en su lugar, y cuándo y con qué lo hiciste. Un formulario de incidencias que pide eso convierte el ruido en material de trabajo. Uno que pide “descripción del error” recoge otra vez “no va”.

Y conviene mirar la dirección contraria, porque ahí el sofista somos nosotros: cerrar un ticket con “arreglado” tampoco comunica nada. No dice qué fallaba, ni a quién le pasaba, ni cómo se comprueba que ya no.

Gorgias como higiene, no como derrota

El sofista no buscaba la verdad: buscaba ganar el argumento. Por eso es un buen modelo de lo que hace un sistema en producción. No te va a mentir con un error rojo y evidente; te va a contestar con seguridad, rápido, en un tono perfectamente convincente, y a veces lo que conteste será falso.

Contra eso solo funciona la carga de la prueba. Quien afirma que está arreglado, lo demuestra. Y “arreglado” tiene un significado exacto: existe un caso concreto que fallaba, ese caso ya no falla, y se sabe por qué fallaba. Sin la tercera parte no hay arreglo, hay una coincidencia con buena prensa.

En epistemología para developers el argumento era que un test no demuestra que el código funcione, solo que todavía no ha fallado. Un intermitente es exactamente ese hueco, pero ocupado: alguien vive dentro del margen de error.

Antes de cerrar uno de estos

Tres cosas, por orden:

• Escribirlo como una frase comprobable. No “a veces falla el envío”, sino “con la sesión caducada, el envío responde 200 y no guarda”. Una frase así se puede atacar; la otra solo se puede archivar.
• Instrumentar antes de tocar. Si no se reproduce, lo urgente es verlo, no curarlo.
• No cerrar por silencio. Un bug que deja de aparecer no está arreglado: está esperando. Normalmente al viernes por la tarde.

Gorgias escribió su tratado para demostrar que el lenguaje no llega a tocar la realidad. En producción pasa lo contrario, y es peor: la toca todo el rato. “No va”, “no se reproduce”, “ya está arreglado” — cada una de esas tres frases decide si alguien va a seguir mirando o no. Y el fallo, mientras tanto, sigue ahí, sin ninguna obligación de existir cuando lo miras.