Depurar, primero con la cabeza, después con los ojos.

Error esporádico en un proceso de la aplicación. Nada más molesto. De cien veces falla tres o cuatro no consecutivas y más allá de esos fallos todo perfecto. Reintenta y sigue un rato largo, hasta el próximo.

Todo lo siguiente de palabra, charlando sin mirar el código:

¿En qué línea es?

En la que consulta los datos de activación del producto.

No tiene sentido, ésos están siempre disponibles desde que la aplicación arranca. Si no están no arranca. Y si se pierden, ¿cómo es que el sistema sigue en los reintentos?

Hay algo que baja esos datos y los vuelve a subir.

Pero el proceso que da error no tiene nada que ver con ello, sólo consulta.

Pero está corriendo casi todo el tiempo. Y entonces, de vez en cuando, se cruza con este otro desconocido que le baja los datos y que luego se los vuelve a subir.

Entonces es un tema de concurrencia. ¿Pero con qué? No hay otro proceso corriendo.

Entonces no es un proceso, es algo que ocurre a partir del front-end, tirado por el usuario.

¿Qué de lo que hace el usuario toca la activación del sistema?

¿No la estamos verificando en cada login?

A ver...

Y ahí, en la primera rutina que miramos, en la primera línea de código que chequeamos, está el maldito bicho, sutil, muy sutil: por espacio de unos pequeños milisegundos, entre que la rutina empieza y termina la verificación, baja los datos.

Ojalá todo se resolviera así. Ni siquiera es muy frecuente. Pero hay algo que es seguro: los errores más difíciles, los más complicados, no están en ninguna parte en especial del código, sino en el maldito vuelo de la mariposa china conjugado con el estornudo de un perro en París y la erupción de una mancha solar.

¿Cómo relacionarlos? ¿Qué hacer?

No sé si hay recetas, éstas son las que me funcionan:

• De ser posible, no pensar sólo. Si no es obvio es que hay que verlo desde muchos ángulos, y la forma más fácil de tener muchos ángulos es tener al menos dos personas sobre lo mismo.
• Si el problema no está en donde se originó el error ni antes de eso en la secuencia de instrucciones mirar el código no servirá para nada.
• ¿Reintento la instrucción que dio el error y funciona? Concurrencia.
• En este punto estamos seguros de que el tiempo tiene algo que ver.
• La frecuencia del error puede acotar las posibilidades: ¿qué es lo que sucede más o menos cada n segundos, horas o días?
• ¿No hay una frecuencia exacta? El usuario puede tener algo que ver.
• Preparar café, porque en este punto estamos ante algo realmente difícil y que puede llevar mucho tiempo. Hay que verle el lado positivo a las cosas: al menos no hay que matarse tratando de reproducir el error, se reproduce sólo.
• Si no lo encontramos y no es crítico, no hacer nada. Esperar a recolectar más información.
• Si no lo encontramos y no es crítico, tal vez sea mejor pensar en otra cosa, distraerse, dejarlo estar. Es el azar el que crea la concurrencia, hay que relacionar azarosamente... eso lo hacemos mejor estando distraídos.
• Aplicar un correctivo, algo que maneje el error y "levante" la situación siempre es posible, pero es sólo una solución temporal a ser aplicada en casos de extrema urgencia. Vamos, tiene que estar ahí.

Paciencia. Esta anécdota terminó bien, pero podríamos haber tenido que convivir con el bicho una temporada.

Y ahora que me acuerdo... mañana me espera uno parecido.