s201: Auto-update del Agente falla aleatorio con datos de oro (primer rescate autónomo del watchdog)
Resumen
El primer rescate autónomo real del watchdog post-swap (validación 2.13.4, 05-07-2026) ejecutó el código diseñado para relanzar o revertir un auto-update fallido, pero mató un proceso vivo retenido por el análisis cloud de Windows Defender e hizo rollback de un binario funcional (versión 2.13.3 debería seguir corriendo, no revertir a 2.13.2).
Timeline
| Fecha | Evento |
|---|---|
| 03-07-2026 | Primer incidente: auto-update fallido, manual workaround |
| 05-07-2026 | Release 2.13.4: validación manos-fuera del watchdog + primer rescate autónomo |
| 05-07-2026 | s201 activado: el rescate funciona pero causa rollback incorrecto |
| 05-07-2026 | Diagnóstico: carrera contra análisis cloud de Defender |
| 05-07-2026 | Cierre con 2.13.5: prescan + watchdog paciente + reconcile version.txt |
Síntomas
- Auto-update 2.13.3 → 2.13.4: arranque inicial del nuevo binario retenido (no killed, freezed)
- Watchdog sondea después de 30 segundos:
"process alive but not responding" - Decisión del watchdog: “el proceso está roto, vamos a matar y relanzar”
- Kill + relanzamiento: el binario sigue sin poder extraer el onefile (análisis aún en marcha)
- Retry final: watchdog decide
"el nuevo .exe no va, revirtiendo a la versión anterior" - Resultado: Agente corriendo 2.13.3 en lugar de 2.13.4 (rollback correcto) O 2.13.2 (rollback excesivo — observado el 05-07)
Causa raíz
Carrera contra Windows Defender:
- Instalación manual: navegador descarga (.exe sin reputación) → usuario espera minutos entre descarga y doble clic → Defender completa análisis cloud → primer arranque limpio
- Auto-update: Agente descarga → ejecuta en segundos → análisis aún a medias →
MpCmdRun(cloud protection) retiene la extracción del onefile del binario congelando el arranque SIN matarlo
Evidencia en traza: "process alive but not responding" (no es un crash, es retencion).
El watchdog de 2.13.4 usaba sondeo impaciente (checks únicos a 30+20 s), insuficiente para detectar retencion temporal.
Impacto
- ❌ Rollback incorrecto de versiones funcionales (capacidad del watchdog validada, pero heurística de decision fallida)
- ❌ Agente termina en versión anterior, no en la nueva
- ⚠️ El diagnóstico manual “Agente no responde” se confunde con “auto-update fallido” (visible en version.txt desincronizado: 2.13.4 con 2.13.3 corriendo)
Resolución (v1.45.11 · Agent 2.13.5)
Tres cambios:
-
Prescan explícito de Defender antes del swap (
_defender_prescan)- Completa el análisis cloud de forma síncrona
- Replica el “tiempo muerto” de la instalación manual
-
Watchdog paciente (
WaitHealthycon poll cada 10 s)- Ventanas de 150/120/120 s en lugar de checks únicos a 30+20 s
- El sondeo respeta el tiempo del análisis cloud
-
Reconcile
version.txtpost-rollback- Detecta y corrige drift tras un rollback que restaura un binario viejo sin tocar version.txt
Testing
3 tests nuevos en tests/agent/test_agent_updater_trace.py:
- Watchdog contiene
WaitHealthy(regresión contra impaciente de 2.13.4) - Prescan graceful sin MpCmdRun
- Reconcile de version.txt tras rollback
Véase también
- [[decision—20260705—prescan-defender-antes-del-swap]]
- [[feature—terminal—auto-update-self-healing-2-13-5]]
- [[feature—terminal—traza-persistente-swap-auto-update]]
- [[concept—general—como-funciona-el-mecanismo-de-auto-update-del-local-agent]]