102904 El destino está sano y dice que no
DESTINO_RECHAZO_LEGITIMAMENTE
Clase común a toda la flota (familia «dependencia»): El proveedor RECHAZÓ legítimamente (4xx). El fallo está en la petición o en la configuración de quien llama.
Qué ha pasado
Un 4xx del destino. NO ES UNA AVERÍA: el servicio funciona y rechaza lo que le mandamos —sala inexistente, chat no encontrado, contenido no admitido—. Contarlo como caída envenena las métricas y manda a mirar donde no es.
Cómo se soluciona
Corregir el DATO, no el servicio: revisar la configuración del destino (sala, chat_id, dirección) en el módulo de canales.
Qué hacer mientras tanto
Ninguno: reintentar un rechazo legítimo solo quema intentos.
Ya costó tiempo
Defecto de flota con TRES apariciones (social-hub, fleet-telemetry y Alcázar) antes de que se corrigiera aquí. El caso más claro es el de fleet-telemetry: el 403 del aislamiento entre clientes se contaba como avería, o sea la seguridad funcionando y disparando una alerta de caída.
Dónde se lanza
motor/clasificar.py:clase_de_fallo → 'rechazado' → CODIGO_POR_CLASE → motor/cola.py:cerrar_entrega, que lo escribe en entregas.codigo (migración 0023) y sale por GET /envios/{id}/entregas
Cómo se lee el código
1- origen: Fortiseg
02- servicio: atalaya
904- clase común a toda la flota: El proveedor RECHAZÓ legítimamente (4xx)