El modo mantenimiento cierra la API para todos con un 503, menos para quien puede ejecutar acciones de sistema, que sigue trabajando y ve un aviso fijo. Se guarda como una marca en Redis (con quién lo activó y cuándo), no en archivos: funciona igual con varias copias de la app.
Paso a paso
- Super adminActiva el mantenimiento con su código
PUT /system/maintenance, con las mismas protecciones de las acciones de sistema: límite, permiso, código y registro. - API¿Ya estaba activo?
Pedir el estado que ya tiene es un conflicto y no se registra dos veces.
- RedisGuarda la marca system:maintenance
Con nombre y fecha. Registro
system_maintenance_enabledenadmin_actions. - Otras personasHacen una petición
- API¿Es ingreso, MFA o cerrar sesión?
Esas rutas siguen abiertas para que quien opera pueda entrar.
/up(el chequeo de Docker) responde normal. - APIResponde normal
- API¿Tiene system.actions.execute?
- Super adminSigue trabajando con el aviso fijo
Cada respuesta trae
X-Maintenance: on, y el shell muestra el aviso arriba hasta que lo apague.
Al apagarlo (el mismo endpoint con enabled: false) se borra la marca, queda system_maintenance_disabled en el registro y “Reintentar” vuelve a funcionar para todos.
Qué ve la persona en cada error
| Código | HTTP | Cuándo | Mensaje en pantalla |
|---|---|---|---|
SERVICE_UNAVAILABLE | 503 | Trazo está en mantenimiento | Trazo está en mantenimiento. Vuelve a intentarlo en unos minutos. |
MAINTENANCE_ALREADY_ENABLED | 409 | Ya estaba activo | El modo mantenimiento ya estaba activo. Actualiza el panel para ver su estado. |
MAINTENANCE_ALREADY_DISABLED | 409 | Ya estaba apagado | El modo mantenimiento ya estaba apagado. Actualiza el panel para ver su estado. |
Dónde está en el código
SetMaintenanceyCacheMaintenanceSwitch.EnforceMaintenance: quién pasa y quién recibe 503.maintenance.ts: el aviso fijo por la cabecera.- Explicación: Módulo System.