fix/sonda-instalador-tres-estados #28
Reference in New Issue
Block a user
No description provided.
Delete Branch "fix/sonda-instalador-tres-estados"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
El panel rechazaba actualizar con 1.1.4 diciendo que su install.ps1 no declara -UpdateInPlace. Era falso: el zip trae UpdateInPlace 8 veces y Sync-AgentTaskPath 3. El bloqueo lo causaba la sonda. const supportsInPlace = supportsProbe.stdout.trim() === 'si'; Cualquier fallo —una excepcion, un codigo de salida distinto de cero, stdout vacio— colapsaba a false. Mientras eso solo elegia entre -UpdateInPlace y -Service, un falso negativo degradaba la instalacion; al convertirlo en un 409 duro paso a ser un candado permanente sobre un artefacto correcto. Por que fallaba en ese servidor y no en la maquina donde se probo no se sabe con certeza. El candidato mas probable es Constrained Language Mode (AppLocker/WDAC son habituales en servidores endurecidos): restringe el acceso a propiedades de objetos .NET como .Parameters mientras `& install.ps1` sigue funcionando, que es justo lo que se observaba. Pero el arreglo no es adivinarlo: - probeInstallerUpdateSupport lee el TEXTO del script y busca la declaracion `[switch]$UpdateInPlace` con [regex]::IsMatch. No compila nada, no toca reflexion y ninguna politica lo bloquea. Anclado a la declaracion y no a una mencion suelta, para que un comentario no de un falso positivo. - Tres estados en vez de dos. Solo un "no" CONFIRMADO bloquea; "desconocido" sigue adelante con el comportamiento anterior y deja asentado POR QUE no se pudo determinar. Un fallo de diagnostico no puede impedir el trabajo. - El estado se decide tambien con el codigo de salida y stderr, no solo con stdout: un execRemote que falla deja stdout vacio y eso se leia como respuesta. Auditado el mismo patron en las otras sondas de Windows, porque dos gobiernan fallos duros: probeWindowsAgentProcess (502 "no esta corriendo"), probeWindowsElevation (409 por privilegios) y probeWindowsTask leian "el comando no respondio" como "la respuesta es no". Ahora todas distinguen los dos casos. Verificado con PowerShell real, y esta vez tambien las rutas de FALLO —que es lo que falto la vez pasada y por lo que esto llego a produccion—: instalador nuevo -> si, instalador del zip 1.1.2 publicado -> no, archivo inexistente -> desconocido, y fallo de lectura -> desconocido. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>