RF07 Control de integración de pedidos Ecommerce (Yoda)

Entendimiento

Controlar que el sistema de Yoda de integración de pedidos Ecommerce está funcionando correctamente.

Situación Actual

La monitorización de las colas de integración de Yoda no es observabilidad en tiempo real, sino un mecanismo reactivo de "limpieza" alojado en GitHub Pipelines.

Mecanismo de GitHub (Gestión de colas fallidas): Existe una tarea programada en GitHub que gestiona la Dead Letter Queue de Yoda. Su función es estrictamente el Reprocesado de Fallos Explícitos: lee mensajes que el sistema intentó procesar pero fallaron (cuyo contenido suele ser el código de pedido) e intenta reinyectarlos. Actúa sobre lo que se sabe que ha fallado.
Limitación de "Muerte Silenciosa": Este proceso opera bajo una política de reintentos finitos. La documentación señala que "a veces se agota el número máximo de intentos", momento en el cual el pedido queda definitivamente huérfano sin que se dispare una alerta de negocio prioritaria.
Carencia de Monitorización de Infraestructura (Latido / Heartbeat): El pipeline es ciego ante la falta de actividad. Si la cola principal de Yoda se cae o se "congela" y dejan de entrar mensajes, GitHub no actúa (no hay mensajes fallidos, simplemente no hay nada). RF07 cubre este vacío mediante un Latido que detecta el "silencio" anómalo — algo que GitHub no hace.

Solución Técnica

Esta necesidad queda cubierta por los procedimientos descritos en RF01, específicamente en el apartado B. Subsistema eCommerce (Pub / Sub eCom).

La solución reutiliza la función de integridad transaction_integrity_controller (GCF_2), que monitoriza las Tablas de Control comparándolas con las datafeeds de raw_osp (pedidos pagados) para detectar discrepancias y reinyectar los pedidos faltantes automáticamente. No desarrollamos nada específico en Yoda — explotamos la infraestructura de control común.

Fuera de Alcance

Exclusiones explícitas

Mantenimiento y Evolución de los GitHub Pipelines (colas fallidas) — El proyecto se limita a implementar una nueva capa de supervisión externa (heartbeat) basada en tablas de control. No incluimos la refactorización, corrección o mantenimiento de los actuales scripts de GitHub Pipelines encargados de gestionar la Dead Letter Queue, ni la modificación de sus políticas de reintento, conforme a lo dispuesto en el apartado Situación Actual.

Intervención en Infraestructura de Yoda — La solución alertará sobre la indisponibilidad de las colas ("Tubería Rota"), pero la resolución técnica de la caída (reiniciar colas, escalar infraestructura en Yoda) es responsabilidad del equipo de soporte de eCommerce/Yoda y queda fuera del alcance de este desarrollo de Data.

Arquitectura

graph LR
    subgraph "Yoda"
        QUEUE["Cola principal"]
        DLQ["Dead Letter Queue"]
        GH["GitHub Pipeline (actual)"]
        DLQ --> GH
    end

    subgraph "Nuevo (RF07 — instancia GCF_2)"
        GCF2["GCF_2 (Supervisor)"]
        TC["Tabla de Control eCom"]
        RAW["raw_osp (datafeeds)"]
    end

    QUEUE -.->|"PIPELINE_STALLED<br/>(sin actividad)"| GCF2
    TC --> GCF2
    RAW --> GCF2
    GCF2 -->|"MISSING_ORDER_BRONZE"| PUBSUB["Re-inyectar en Pub/Sub"]
    GCF2 -->|"PIPELINE_STALLED"| ALERT["Alerta SRE"]