Encontré el problema buscando otra cosa, que ya es mi método de diagnóstico favorito: diez días de ingresos al taller sin un solo aviso en el grupo interno de WhatsApp, y nadie en el equipo lo había notado. Nadie extraña un canal que solo informa, así que esos diez días mudos parecieron diez días tranquilos de servicio técnico.
El sistema debía mandar al grupo un aviso por cada equipo que entra a reparación, con el resumen del caso, las fotos y el PDF de ingreso. Con eso el técnico sabe qué le va a caer antes de que la cámara llegue a su mesa, y ventas contesta cuando el cliente llama a preguntar. Sin el aviso, el dato se queda en el sistema y nadie lo mira.
El token nuevo salió y el taller siguió con el viejo
Rotamos el token del lado de mensajería, la credencial que autoriza a un sistema a enviar mensajes por la API de WhatsApp. El sistema del taller siguió presentando el anterior, así que cada intento recibió un 401, la respuesta con la que una API avisa que esa credencial no sirve. Fueron 68 envíos fallidos, 9 de ellos ingresos que nunca se anunciaron.
El sistema anotó cada rechazo en un log que nadie abre, salvo cuando ya anda buscando un problema. Era un timbre con el cable cortado: nadie se queja del silencio y uno asume que no vino nadie.
Un log sin lector no es monitoreo
Cambien mi opinión
El deploy era el culpable obvio
Pensé que el código de envío se había roto en un deploy, porque habíamos tocado esa parte hacía poco. El código estaba igual.
Lo confirmamos con un endpoint de solo lectura, una consulta que devuelve 200 si la credencial sirve y 401 si no, sin publicar ningún mensaje. Respondió 401. Probarlo con un envío real habría metido un aviso duplicado en el grupo.
Reenviar los 9 avisos sin inventar el formato
Con el token actualizado los avisos nuevos volvieron a salir, pero los 9 ingresos de esos diez días seguían sin anunciar. Escribimos un script de reenvío que reutiliza las funciones de producción en vez de rearmar los mensajes, porque un aviso con otro formato no le genera confianza a nadie.
Le pusimos tres frenos de mano: corre en dry-run por defecto, o sea imprime qué enviaría sin enviar nada; se niega a arrancar si el sistema no está corriendo en su modo de siempre; y omite los equipos ya entregados, porque anunciar el ingreso de una cámara que el cliente recogió hace una semana solo confunde. Reanunciamos los 9 ingresos.
Dos semanas después, el worker desapareció
La plataforma de mensajería migró y el worker dedicado al grupo, el proceso que solo mandaba esos avisos internos, se quedó en el camino sin dejar nota. Esta vez la brecha se detectó antes de que un ingreso se quedara sin anunciar, porque ya sabía que el canal podía quedarse mudo sin avisar: comparé los ingresos de la base de datos contra el historial del chat y cuadraron todos, 0 eventos perdidos contra 9 de la primera vez.
Dos timbres para la misma puerta, uno sin dueño
Debajo había dos caminos para lo mismo. Los mensajes a clientes salían por la API principal y los avisos del grupo por un atajo propio, con su credencial y su proceso aparte. Dos rutas son dos lugares donde un token puede quedar viejo, y la segunda no tenía dueño.
Quitamos el atajo. Los avisos internos salen por la misma API con la que el equipo le escribe a un cliente, y el log anota también los éxitos para poder contarlos. Renovar el token cerró este incidente; borrar la segunda ruta debería evitar los que venían detrás.
Quedan dos cosas pendientes: no hay alerta cuando el grupo pasa un día hábil sin avisos, y el cruce contra el historial del chat sigue siendo manual. Cada canal interno tiene ahora un responsable con nombre aunque solo informe, y antes de tocar una credencial la probamos con la consulta que no publica nada. El marcador va 9 ingresos sin anunciar la primera vez y 0 la segunda.
