From be45f950b800c2f1042b26caa1f3a6c0f9cbb575 Mon Sep 17 00:00:00 2001
From: marcos <mdiaz@aduanasoft.com.mx>
Date: Mon, 10 Aug 2026 12:27:01 -0600
Subject: [PATCH] fix(crm): registra las tareas del carril en Celery, sin lo
 cual nada se drenaba

Delta de core/celery_app.py que se me quedo fuera al portar el carril. El sintoma era
enganoso: el encolado se veia perfecto -- fila en crm.efc_sync_outbox, status pending,
sin error -- pero el worker rechazaba la entrega con "Received unregistered task of
type 'expediente_gateway.deliver_outbox_row'" y la fila se quedaba en pending con 0
intentos PARA SIEMPRE. Ni el despacho inmediato ni el barrido existian.

  - include: api.v1.modules.crm.expediente_gateway.tasks
  - beat: sweep_outbox y sweep_file_outbox cada 120 s, sweep_expediente_gaps cada
    300 s. Los intervalos son los del carril de referencia de Anexo22. El reintento
    NO es exponencial a proposito: el backoff corto vive en el cliente HTTP y el
    largo es este barrido de intervalo fijo.

Verificado de punta a punta con los dos sistemas cableados. Desde EFC, no desde el
CRM:

  pedimento_app : CRM-2-EXP2026-08-002        (el storage_token del CRM)
  patente/aduana/clave_pedimento/regimen: None  <- provisional de verdad
  pedimento_expediente: estado=provisional, crm_expediente_id=3, folio=EXP2026-08-002
  organizacion  : Aduanasoft (hub_tenant_slug=aduanasoft, is_verified=True)
  licencia      : 5 GB, asi que la subida no falla por cuota

El resolver mapeo tenant 11 -> organizacion por slug, que es el puente 1:1 acordado.
Las cinco tareas quedan registradas en el worker y los tres barridos en el beat.

Ref: T2026-08-046

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---
 backend/core/celery_app.py | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/backend/core/celery_app.py b/backend/core/celery_app.py
index 08b1c58..40b25c3 100644
--- a/backend/core/celery_app.py
+++ b/backend/core/celery_app.py
@@ -96,6 +96,10 @@ def _reset_rls_context_from_task(task_id=None, task=None, **_):
 celery_app.conf.update(
     include=[
         "api.v1.modules.core.help_center.tasks",
+        # Sin esta línea el worker rechaza las tareas del carril con "Received unregistered
+        # task of type 'expediente_gateway.deliver_outbox_row'": la fila queda en `pending`
+        # con 0 intentos y NUNCA se drena, aunque el encolado se vea perfecto.
+        "api.v1.modules.crm.expediente_gateway.tasks",
         # Agrega aquí las tareas de tu proyecto:
         # "api.v1.modules.example.tasks",
     ]
@@ -120,6 +124,25 @@ celery_app.conf.beat_schedule = {
         "task": "cleanup_orphan_layout_imports",
         "schedule": 3600.0,
     },
+    # Carril CRM -> EFC. Los tres intervalos vienen del carril de referencia de Anexo22: 120 s para
+    # las dos colas y 300 s para la reconciliación. El reintento NO es exponencial a propósito —el
+    # backoff corto vive en el cliente HTTP y el largo es este barrido de intervalo fijo.
+    #
+    # Estos barridos son la red que atrapa la ventana entre el encolado y el commit: el despacho
+    # inmediato puede llegar al worker antes de que la transacción confirme, no encontrar la fila
+    # y darse por vencido. Aquí se recoge.
+    "efc-sweep-outbox-every-2-min": {
+        "task": "expediente_gateway.sweep_outbox",
+        "schedule": 120.0,
+    },
+    "efc-sweep-file-outbox-every-2-min": {
+        "task": "expediente_gateway.sweep_file_outbox",
+        "schedule": 120.0,
+    },
+    "efc-sweep-expediente-gaps-every-5-min": {
+        "task": "expediente_gateway.sweep_expediente_gaps",
+        "schedule": 300.0,
+    },
 }
 
 if __name__ == "__main__":