Anécdota de un software lento

No voy a tratar de ser gracioso, pero el otro día me pasó algo de lo cual reí para no llorar. Es muy común en programación tener errores de todo tipo, y quizás el amable lector (si sabe un poco de programación), sepa que es error de novato olvidarse de poner el -punto y coma- al finalizar una sentencia de código. Pero a mí esas cosas son cosas del pasado, no seas pesado.

Los softwares no sólo fallan por la falta de un componente sintáctico, o la adicción, a veces los errores trascienden lo cotidiano y llegan a lares que no son fáciles de descifrar. En este caso, fue tan estúpido el problema que no lo había visto, en serio, fue estúpido.
—Cuéntame a ver, ¿qué fue lo que pasó?

Para esto, me gustaría contaros que llevo un proyecto de un bot de Telegram, al que apodaré #botie; y últimamente he estado mejorando muchas cosas, ya que éste ha sido el resultado de varias de las cosas que voy conociendo, y cosas molonas que veo por ahí y me gusta implementarle (o cosas a pedido de los amigos). Entonces, una de esas mejoras fue integrar todos los bots que tengo (primero comencé con tres de ellos) y crear un bot que administre a los demás bots. Ése era la idea, pues.

Y así fue como hice; copié los directorios de los proyectos a su nueva casita, configuré un archivo de instalación para que el administrador (más bien, gestor) pudiera iniciarlos, pararlos, comunicarse con ellos, saludarlos y demás. Sin embargo, como el específico proyecto de la botie no es uno solo, son tres poderes en uno, uno que son tres, no se pueden contar, son tan unidos por el socket que son perfectamente uno, amén. Yo apagué y mudé el directorio, pero no apagué los otros dos servicios del cual el principal depende, llevando a una fragmentación del espacio tiempo (?). Analógicamente, fue como la paradoja de viajar al pasado y matar a tu abuelo. Resulta que los otros dos servicios hacen uso (cada uno, pues) de dos archivos principales: uno de almacenamiento y otro de socket virtual unix (mecanismo de comunicación entre procesos en la misma máquina, de forma bidireccional); y estos últimos ya no estaban en la ruta anterior, la que los servicios que aún activos, intentaban utilizar. Sin embargo, podían accederlo bajo incertidumbre.

Eso fue lo que pasó, y comenzó días antes al 20 de junio (éste fue cuando se dio el diagnóstico); y hasta el 3 de julio, fue que me di cuenta de ese problema de coherencia. El haber estado así generaba un lag en el momento de responder a los mensajes enviados al bot, que curiosamente funcionaba cuando se recibían dos mensajes o más, pero uno, no. Además, no me explico el porqué, pero me da curiosidad pillar el porqué, volver a replicar si es el caso, sé que estás ahí, no te escondas...

Ahora si podemos seguir implementando las otras cosas que estaban en lista de espera, pues. Nadie puede explicar por qué nadie se tomó la molestia de mirar por qué una vez los otros dos servicios marcaron un error, pero siguieron su funcionamiento sin interrupciones. Si se hubiera revisado el porqué, hoy en día no tendríamos un problema que (para bien o para mal) no afectó más que la experiencia de usuario.

Si te interesa conocer más de estos sockets:
Socket Unix
Pregunta ¿Cuál es la diferencia entre el socket Unix y el socket TCP/IP?

—Así nadie vendrá a decirme que no os enseño nada.