[RI-270625] - Subida masivas

1. Resumen del Incidente

Fecha de Inicio: Primera semana de junio de 2025 (aproximadamente lunes 2 de junio)
Descripción General: Se reportó una intermitencia en la funcionalidad de carga masiva de archivos utilizados para la modificación de datos en el sistema. El problema afectaba a usuarios que intentaban ejecutar procesos de importación en lote, resultando en cargas incompletas, procesos que no finalizaban, y en algunos casos, imposibilidad de ejecutar nuevas cargas debido a saturación en las colas de ejecución.

Se realizó una revisión técnica poco después del reporte, pero no se logró identificar una causa clara.
Para mejorar la visibilidad del sistema, se procedió a instalar herramientas de telemetría, métricas y logging en nuevos servidores, con el objetivo de analizar el comportamiento interno del proceso de importación.
El análisis fue pausado temporalmente por prioridades operativas y fue retomado el 25 de junio de 2025.

A través del análisis con telemetría y métricas activas, se identificaron dos causas fundamentales que provocaban el mal funcionamiento del sistema:

Los procesos de importación se ejecutan a través de la interfaz de línea de comandos (CLI), que por defecto tenía configurado un tiempo máximo de ejecución bajo.
En algunos casos, este límite de tiempo era alcanzado antes de que finalice el proceso de importación, lo que provocaba su terminación abrupta sin una gestión adecuada del error.
Acción Correctiva: Se eliminó el límite de tiempo en la ejecución CLI (php artisan horizon) para permitir que los procesos puedan completarse sin ser interrumpidos por restricciones del entorno.

En la implementación anterior, los errores durante el procesamiento del job eran capturados (con try/catch), pero no se relanzaban mediante excepciones.
Esto impedía que Laravel (o Horizon) detectara que el job había fallado. Como resultado:
- El proceso no se registraba como fallido.
- La cola quedaba ocupada, generando cuellos de botella por trabajos "fantasma".
- Se generaban falsos positivos: el sistema consideraba que los jobs se habían ejecutado correctamente, cuando en realidad habían fallado silenciosamente.
Acción Correctiva:
- Se refactorizó la lógica del job para que las excepciones no sean suprimidas silenciosamente.
- Toda la lógica de error fue trasladada al método failed(), permitiendo a Laravel encargarse automáticamente de marcar el job como fallido.
- Cuando ocurre una excepción:
  - Esta se lanza directamente.
  - Laravel la captura, la reporta a Sentry, y marca el job como fallido.
- Además, se definió explícitamente el número máximo de reintentos permitidos por job, evitando loops silenciosos y bloqueos en la cola.

Validación de comportamiento post-error mediante pruebas en staging.
Se estableció como política estándar:
- No usar try/catch para ocultar errores en procesos críticos en segundo plano.
- Delegar el manejo de fallos al mecanismo nativo de Laravel.
- No imponer límites de ejecución a nivel de CLI para procesos de larga duración.

Auditar otros jobs que realicen operaciones pesadas o masivas para validar que cumplen con las nuevas reglas de manejo de errores.
Realizar pruebas controladas de carga masiva para validar la estabilidad del nuevo flujo.
Implementar un monitor automático de procesos pendientes para evitar acumulación en cola.
Documentar formalmente la nueva política de desarrollo para tareas en background en el sistema.

Este incidente reveló deficiencias tanto en la configuración del entorno como en la lógica de manejo de errores.
Las acciones implementadas mejoran la trazabilidad de fallos, previenen cuellos de botella y aseguran que el sistema responda adecuadamente ante errores.
Se recomienda mantener la telemetría activa durante las próximas semanas para validar que el comportamiento actual del sistema se mantiene estable y sin recurrencia del problema.

27 June 2025