fix(cras-install): dejar de dar por buena una actualizacion que no surtio efecto #24

hreyes · 2026-07-31T16:29:18Z

hreyes commented

2026-07-31 16:29:18 +00:00

El run de Windows terminaba en verde sobre un servidor que seguia con la version
anterior. La verificacion no podia detectarlo:

El sello config.version ausente se toleraba SIEMPRE. Los agentes anteriores a
1.1.1 no lo escribian, asi que al actualizar uno de esos deployed llegaba
vacio y no se comprobaba ninguna version — justo la combinacion que importa.
Ahora, en una ACTUALIZACION, un sello ausente es un fallo: el binario nuevo lo
escribe en ensure_runtime_layout(), asi que su ausencia significa que lo que
corre no es el que se instalo. La tolerancia se queda solo en instalacion nueva.
Get-Process -Name responde "hay un proceso con ese nombre", no "corre el
binario que instale". Se compara la RUTA del ejecutable; si no es legible no se
concluye que sea ajeno, porque un proceso de SYSTEM no la expone sin elevacion.
Se interroga la tarea programada a fondo: su accion dice DONDE arranca el
agente de verdad y se asienta en la bitacora (el dato que habria explicado esto
en diez segundos), y cuando el agente no reporta su ruta —nada anterior a 1.1.1
lo hace— se usa la de la tarea en vez del default.

Y dos correcciones de lo anterior:

needsElevation exigia admin en cuanto la tarea EXISTIA, bloqueando de entrada
toda actualizacion sobre un servidor ya instalado. Ahora depende de que la
tarea corra como SYSTEM, que es lo que de verdad obliga a elevar; y el token
filtrado por UAC deja de rechazarse por adelantado: se intenta y se reporta lo
que responda el servidor.
-UpdateInPlace se pasaba siempre, pero solo existe desde 1.1.3 y install.ps1
usa [CmdletBinding()], asi que con un artefacto anterior fallaba con
NamedParameterNotFound sin ejecutar una linea. Se le pregunta a PowerShell por
el param() del propio artefacto en vez de mantener una tabla de versiones.

Verificar comparte las dos sondas nuevas para que no pueda contradecir al
instalador, y gana un chequeo de "el arranque apunta a la instalacion".

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

El run de Windows terminaba en verde sobre un servidor que seguia con la version anterior. La verificacion no podia detectarlo: - El sello config\.version ausente se toleraba SIEMPRE. Los agentes anteriores a 1.1.1 no lo escribian, asi que al actualizar uno de esos `deployed` llegaba vacio y no se comprobaba ninguna version — justo la combinacion que importa. Ahora, en una ACTUALIZACION, un sello ausente es un fallo: el binario nuevo lo escribe en ensure_runtime_layout(), asi que su ausencia significa que lo que corre no es el que se instalo. La tolerancia se queda solo en instalacion nueva. - `Get-Process -Name` responde "hay un proceso con ese nombre", no "corre el binario que instale". Se compara la RUTA del ejecutable; si no es legible no se concluye que sea ajeno, porque un proceso de SYSTEM no la expone sin elevacion. - Se interroga la tarea programada a fondo: su accion dice DONDE arranca el agente de verdad y se asienta en la bitacora (el dato que habria explicado esto en diez segundos), y cuando el agente no reporta su ruta —nada anterior a 1.1.1 lo hace— se usa la de la tarea en vez del default. Y dos correcciones de lo anterior: - needsElevation exigia admin en cuanto la tarea EXISTIA, bloqueando de entrada toda actualizacion sobre un servidor ya instalado. Ahora depende de que la tarea corra como SYSTEM, que es lo que de verdad obliga a elevar; y el token filtrado por UAC deja de rechazarse por adelantado: se intenta y se reporta lo que responda el servidor. - -UpdateInPlace se pasaba siempre, pero solo existe desde 1.1.3 y install.ps1 usa [CmdletBinding()], asi que con un artefacto anterior fallaba con NamedParameterNotFound sin ejecutar una linea. Se le pregunta a PowerShell por el param() del propio artefacto en vez de mantener una tabla de versiones. Verificar comparte las dos sondas nuevas para que no pueda contradecir al instalador, y gana un chequeo de "el arranque apunta a la instalacion". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

hreyes added 1 commit 2026-07-31 16:29:19 +00:00

fix(cras-install): dejar de dar por buena una actualizacion que no surtio efecto 9a4124d636

El run de Windows terminaba en verde sobre un servidor que seguia con la version
anterior. La verificacion no podia detectarlo:

- El sello config\.version ausente se toleraba SIEMPRE. Los agentes anteriores a
  1.1.1 no lo escribian, asi que al actualizar uno de esos `deployed` llegaba
  vacio y no se comprobaba ninguna version — justo la combinacion que importa.
  Ahora, en una ACTUALIZACION, un sello ausente es un fallo: el binario nuevo lo
  escribe en ensure_runtime_layout(), asi que su ausencia significa que lo que
  corre no es el que se instalo. La tolerancia se queda solo en instalacion nueva.
- `Get-Process -Name` responde "hay un proceso con ese nombre", no "corre el
  binario que instale". Se compara la RUTA del ejecutable; si no es legible no se
  concluye que sea ajeno, porque un proceso de SYSTEM no la expone sin elevacion.
- Se interroga la tarea programada a fondo: su accion dice DONDE arranca el
  agente de verdad y se asienta en la bitacora (el dato que habria explicado esto
  en diez segundos), y cuando el agente no reporta su ruta —nada anterior a 1.1.1
  lo hace— se usa la de la tarea en vez del default.

Y dos correcciones de lo anterior:

- needsElevation exigia admin en cuanto la tarea EXISTIA, bloqueando de entrada
  toda actualizacion sobre un servidor ya instalado. Ahora depende de que la
  tarea corra como SYSTEM, que es lo que de verdad obliga a elevar; y el token
  filtrado por UAC deja de rechazarse por adelantado: se intenta y se reporta lo
  que responda el servidor.
- -UpdateInPlace se pasaba siempre, pero solo existe desde 1.1.3 y install.ps1
  usa [CmdletBinding()], asi que con un artefacto anterior fallaba con
  NamedParameterNotFound sin ejecutar una linea. Se le pregunta a PowerShell por
  el param() del propio artefacto en vez de mantener una tabla de versiones.

Verificar comparte las dos sondas nuevas para que no pueda contradecir al
instalador, y gana un chequeo de "el arranque apunta a la instalacion".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

acazares merged commit a89504456e into development

2026-07-31 16:29:42 +00:00

acazares deleted branch fix/windows-actualizacion-silenciosa

2026-07-31 16:29:42 +00:00

acazares referenced this issue from a commit

2026-07-31 16:29:43 +00:00

fix(cras-install): dejar de dar por buena una actualizacion que no surtio efecto (#24)

hreyes referenced this issue from a commit

2026-07-31 17:16:13 +00:00

Merge branch 'development' into fix/windows-actualizacion-silenciosa

Sign in to join this conversation.