El compose de produccion no declaraba ninguna EFC_*, asi que el carril nacia muerto
alla: `EfcClient.is_configured` era False y todo el enganche hacia no-op en silencio.
Van en los TRES servicios y no solo en el backend, porque cada uno hace una parte:
- backend encola al crear el expediente y despacha la entrega inmediata;
- celery_worker EJECUTA la entrega (`deliver_outbox_row` / `deliver_file_outbox_row`).
Si solo el backend las tuviera, el encolado se veria perfecto y nada
se entregaria nunca -- es exactamente el modo de fallo que ya nos
costo un diagnostico hoy, cuando el worker no tenia registradas las
tareas del carril;
- celery_beat dispara los tres barridos, que son la red que atrapa lo que el
despacho inmediato no alcanzo. Sin el, una caida de EFC deja la cola
detenida para siempre.
Se declaran las ocho aunque seis queden vacias por default. No es simetria: una
variable no declarada en el compose NO llega al contenedor, asi que editarla en el .env
no surte efecto y el sintoma parece un problema de red. Ya paso con EFC_API_VERIFY_SSL
en el compose de desarrollo, que solo pasa dos de las ocho.
EFC_API_URL vacia = carril apagado, y es el default a proposito: desplegar este cambio
no enciende nada. Encenderlo exige EFC_API_URL y una EFC_API_KEY identica a la
CRM_INTEGRATION_API_KEY del lado de EFC, cuyo permiso es fail-closed.
Ref: T2026-08-046
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
