diff --git a/README.md b/README.md index 66151a4..ac2d281 100644 --- a/README.md +++ b/README.md @@ -41,6 +41,48 @@ graph TD ``` *(Diagram updated for planned flow)* +## Decisiones de diseño de la cola de respuestas (MVP) +1) Persistencia: 100% persistente (tabla única). +2) Worker: continuo en background. +3) Locking: status=processing (sin lease). +4) Orden: sin orden estricto por chat. +5) Reintentos: sin reintentos en MVP. +6) Errores: 4xx = fallo definitivo; 5xx/red = fallo (sin reintentos). +7) Idempotencia: no. +8) Esquema DB: tabla única response_queue. +9) Transporte: envío desde ResponseQueue (fetch directo a Evolution API). +10) Concurrencia: N workers globales. +11) Integración: encolar y worker continuo (arranca con el servidor). +12) Configuración: defaults fijos (sin nuevas env vars por ahora). +13) Limpieza: sin limpieza/retención de historiales (por ahora). +14) Seguridad: no enviar al número del bot (CHATBOT_PHONE_NUMBER). +15) Pruebas: unitarias de cola con mocks de fetch. + +## Arquitectura de la cola persistente (MVP) +- Estados: queued | processing | sent | failed. +- Campos mínimos por mensaje: id (PK), recipient, type (text), payload_text, status, attempts (0), last_error (nullable), created_at, updated_at. +- Índices recomendados: (status, created_at) para seleccionar pendientes rápidamente. +- Sin orden estricto por chat; el envío puede intercalarse entre destinatarios. +- Concurrencia: N workers globales operando en bucle, cada uno toma mensajes en estado queued y los marca processing. + +## Flujo del worker continuo (MVP) +- Se inicia al arrancar el servidor (desactivado en tests). +- Ciclo: seleccionar hasta un pequeño batch de mensajes queued, marcar processing, enviar a Evolution API, marcar sent o failed según respuesta. +- Sin reintentos; logs mínimos y no sensibles. + +## Limitaciones explícitas del MVP +- Sin backoff ni reintentos. +- Sin orden garantizado por chat. +- Sin idempotencia ni limpieza automática. +- Sin lease; en caso de crash podrían quedar mensajes en processing que requerirán recuperación manual en una iteración futura. + +## Plan incremental posterior +- Añadir reintentos con backoff exponencial y jitter. +- Garantizar orden por chat (serialización por recipient). +- Introducir lease (lease_until) para tolerancia a fallos y recuperación. +- Limpieza/retención y métricas/observabilidad. +- Opcional: idempotencia e índices adicionales. + ## ✅ Current Status (as of latest commit, all tests passing) ### Implemented - Webhook server setup (`src/server.ts`) receiving Evolution API events. diff --git a/STATUS.md b/STATUS.md index d6d99eb..a1220e4 100644 --- a/STATUS.md +++ b/STATUS.md @@ -34,7 +34,7 @@ - **Cola de Respuestas** - Sin integración con Evolution API - No envía mensajes realmente - - **Persistencia en DB pendiente** (importante para evitar pérdida de mensajes en reinicios) + - **Persistencia en DB en progreso** (importante para evitar pérdida de mensajes en reinicios) - **Validaciones** - Permisos de usuario no implementados - Sin verificación de pertenencia a grupos @@ -42,12 +42,14 @@ - Acciones de tareas no implementadas (crear/listar) ## ➡️ Próximos Pasos Prioritarios -1. Implementar procesamiento de cola de respuestas -2. Conectar comandos con servicio de tareas -3. Añadir validaciones de seguridad -4. Completar CRUD de tareas -5. Manejar eventos de actualización de grupos -6. **Persistir cola de respuestas en DB** (para fiabilidad) +1. Documentar decisiones del MVP de cola persistente (este cambio) +2. Definir esquema de DB (tabla única response_queue) e incluirlo en initializeDatabase +3. Actualizar tests de DB para la nueva tabla +4. Adaptar ResponseQueue.add a persistente (insert en DB) +5. Implementar worker continuo básico (N workers, sin reintentos, sin orden estricto) +6. Integrar el worker en server.start (desactivado en entorno de test) +7. Añadir tests unitarios de la cola con mocks de fetch +8. Iteración siguiente: reintentos con backoff exponencial y mejoras de observabilidad ## 🔧 Archivos Clave a Modificar - `src/services/response-queue.ts`