La actualizacion ya fallaba ruidosamente en vez de mentir, pero el arreglo no
podia llegar al servidor: el install.ps1 que se ejecuta viaja DENTRO del zip, y
el artefacto 1.1.3 se construyo antes de que el instalador aprendiera a
realinear la tarea. Verificado sobre el zip: trae -UpdateInPlace y cero
Sync-AgentTaskPath. Un instalador ya publicado no se arregla hacia atras.
- alignWindowsTask realinea la accion de la tarea por SSH tras instalar el
binario, conservando disparador, principal, ajustes y argumentos, y asienta la
ruta ANTERIOR y la nueva para que el cambio sea reversible si la ruta declarada
estuviera mal. Si no se puede corregir, aborta con 409 nombrando ambas: seguir
significaria arrancar a sabiendas el binario viejo. Funciona con cualquier
artefacto ya distribuido.
- restartWindowsAgent rearranca y espera a que corra el binario del prefijo, no
cualquier proceso con ese nombre. Vive en cras-install y no en
cras-agent-control porque este es el modulo de abajo; al reves habria un ciclo.
Y el diagnostico deja de ser una tarea para el operador. El error de sello
ausente decia "revisa a que binario apunta el arranque automatico" cuando el
panel YA lo sabe, y la bitacora del run donde si estaba no la encontraba nadie
("no se donde verlo"). Ahora se sondea tarea y proceso ANTES de evaluar el sello
y el mensaje nombra a que apunta la tarea, desde donde corre el proceso, y la
cola de CloudRestoreAS-crash.log — que runner.py escribe precisamente para esto
y que nunca se leia. El banner de error apunta al run por numero.
startOnWindows deja de esperar por nombre y usa la misma sonda de ruta, para que
Verificar no pueda contradecir al instalador.
PowerShell generado validado con PowerShell real: los seis scripts parsean, y el
de realineacion ejercitado contra una tarea simulada reapunta la accion Exec,
conserva los argumentos y respeta las acciones que no son Exec.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
hreyes
3572aa974b