Files
PANEL_BASES_ANEXO24/src
hreyes d332b2d11a fix(cras-install): no confundir "no pude averiguarlo" con "no lo soporta"
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>
2026-07-31 13:12:35 -06:00
..