v1.7.0 - Fix: Corregido error 500 en SLA Dashboard

- Fix error de sintaxis SQL en cálculo de tickets 'at risk'
- Fix error de timezone (offset-naive vs offset-aware datetimes)
- Implementado sistema completo de SLA Management
- Agregados endpoints: /sla/dashboard, /sla/violations, /sla/at-risk
- Creadas vistas frontend para dashboard, violaciones y tickets en riesgo
- Actualizado sistema de Celery para monitoreo automático de SLAs
- Mejorada configuración de categorías con tiempos SLA personalizables
- Corregidos problemas de proxy en configuración de Vite
- Agregado troubleshooting guide en README

Archivos principales modificados:
- backend/app/api/v1/endpoints/sla.py (nuevo)
- backend/app/api/schemas/sla.py (nuevo)
- frontend-internal/src/routes/sla/ (nuevo módulo completo)
- workers/app/tasks/sla_tasks.py (queries async mejoradas)

Documentación: docs/changelog-2026-02-17.md
This commit is contained in:
2026-02-17 08:22:32 -07:00
parent 42a5bb54cc
commit 75726d915f
17 changed files with 2504 additions and 143 deletions

View File

@@ -0,0 +1,119 @@
# Changelog - 17 de Febrero 2026
## Versión 1.7.0 - Corrección Sistema de SLA Dashboard
### 🐛 Bugs Corregidos
#### Error 500 en Endpoint `/api/v1/sla/dashboard`
**Problema Identificado:**
El endpoint de SLA Dashboard estaba generando errores 500 (Internal Server Error) al intentar cargar las métricas. Se identificaron dos problemas críticos en las queries SQL:
1. **Error de Sintaxis SQL - "missing FROM-clause entry for table 'ticket'"**
- **Causa:** Uso incorrecto de `text()` con referencias al modelo SQLAlchemy dentro de expresiones SQL sin formato
- **Ubicación:** Cálculo de tickets "at risk" en queries de Response y Resolution SLA
- **Expresión problemática:**
```python
text("INTERVAL '20%' * (Ticket.sla_response_due - Ticket.created_at)")
```
2. **Error de Timezone - "can't subtract offset-naive and offset-aware datetimes"**
- **Causa:** Comparación entre `datetime.now(timezone.utc)` (timezone-aware) y campos de base de datos `TIMESTAMP WITHOUT TIME ZONE` (timezone-naive)
- **Ubicación:** Todas las comparaciones temporales en queries SLA
### ✅ Solución Implementada
#### Archivo Modificado:
- `backend/app/api/v1/endpoints/sla.py`
#### Cambios Realizados:
1. **Eliminación de SQL Crudo con `text()`**
- Se reemplazaron todas las expresiones `text()` con funciones nativas de SQLAlchemy
- Se utilizó `func.extract('epoch', ...)` para cálculos temporales seguros
2. **Corrección de Timezone**
- Se introdujo `db_now = func.now()` para usar la función `NOW()` de PostgreSQL directamente
- `now = datetime.now(timezone.utc)` se mantiene solo para cálculos en Python (ej: `period_start`)
- Se reemplazaron todas las comparaciones `now > Ticket.sla_response_due` por `db_now > Ticket.sla_response_due`
3. **Cálculo de Tickets "At Risk" Mejorado**
- **Lógica:** Un ticket está "en riesgo" cuando ha consumido más del 80% del tiempo disponible
- **Nueva expresión segura:**
```python
func.extract('epoch', db_now - Ticket.created_at) >
(func.extract('epoch', Ticket.sla_response_due - Ticket.created_at) * 0.8)
```
#### Secciones del Código Corregidas:
1. **Dashboard Principal** (líneas 93-280)
- Query de Response SLA
- Query de Resolution SLA
- Contadores de violaciones activas
2. **Lista de Violaciones** (líneas 355-395)
- Filtro por tipo de SLA (response/resolution)
- Queries con timezone corregido
3. **Tickets en Riesgo** (líneas 505-540)
- Cálculo del umbral de riesgo
- Filtrado de tickets según porcentaje de tiempo consumido
### 🧪 Validación
**Pruebas Realizadas:**
- ✅ Endpoint `/api/v1/sla/dashboard?days=30` responde correctamente (200 OK)
- ✅ Backend reiniciado sin errores de sintaxis
- ✅ Logs del backend sin excepciones de SQLAlchemy
- ✅ Frontend carga el dashboard de SLA sin errores 500
**Estado del Servicio:**
```
servicemanager-backend: Up and healthy
servicemanager-db: Up and healthy
servicemanager-redis: Up and healthy
```
### 📊 Impacto
**Alta Prioridad:** Este fix desbloquea una funcionalidad crítica del sistema de gestión de SLAs, permitiendo a los equipos de soporte visualizar:
- Métricas de cumplimiento de Response SLA
- Métricas de cumplimiento de Resolution SLA
- Tickets en riesgo de violar SLA
- Violaciones activas
- Tendencias por categoría y prioridad
### 🔍 Detalles Técnicos
**Stack Tecnológico:**
- Python 3.11
- FastAPI (async)
- SQLAlchemy 2.0 (async ORM)
- PostgreSQL
- Docker
**Patrón de Solución:**
- Uso de funciones SQL nativas a través de SQLAlchemy ORM
- Separación entre datetime Python (timezone-aware) y SQL timestamps (timezone-naive)
- Eliminación de strings SQL dinámicos en favor de expresiones type-safe
### 📝 Notas para Desarrollo Futuro
**Lecciones Aprendidas:**
1. Siempre usar `func.now()` para comparaciones temporales en queries SQL
2. Evitar `text()` cuando sea posible; preferir funciones SQLAlchemy
3. Los campos `TIMESTAMP WITHOUT TIME ZONE` en PostgreSQL deben compararse con valores timezone-naive o funciones SQL
**Recomendaciones:**
- Considerar migración de campos timestamp a `TIMESTAMP WITH TIME ZONE` en futuras versiones
- Agregar tests de integración para endpoints SLA
- Implementar monitoreo de queries SQL lentas
---
**Desarrollador:** GitHub Copilot
**Fecha:** 17 de Febrero 2026
**Tipo:** Bug Fix
**Severidad:** Alta
**Branch:** main
**Versión:** 1.7.0