Issues / #3653

#3653 [Engine] UPDATE.bat reports updated after failing to upgrade the engine

open · @ogrrd · 2 comentários · No GitHub

Setup & installServer & APINVIDIA / CUDAWindowsLinux

Descrição

## Correction to the original report

This issue is narrowed to the update-result messaging supported by the local update log. The original title asserted a confirmed WSL readiness/orphan-process defect; that causal diagnosis was not established. I withdraw the claims that readiness can never match under WSL, that reparenting caused this incident, and that 161 GB was pinned RAM. Sorry for presenting those explanations as confirmed.

## Problem

The legacy `UPDATE.bat` path warns that it could not update the engine, keeps engine 0.1.44.1, then finishes with `[ok] Strata is updated (engine 0.1.44.1)`. The final result should clearly distinguish a partial update from a successful engine upgrade.

A separate local orchestration script compounded this: it treated a successful image request as proof of an engine upgrade and wrote `DONE engine-updated` without checking the installed version. That message belongs to our local wrapper, not Strata, and was our error.

## Environment

- Windows 11 with WSL2 interop; RTX 5090 32 GB VRAM; 96 GB RAM.
- Source checkout at `011c9e600a93bbc9fd451c563501b5831c32bbca` (serve 0.2.2).
- Installed engine 0.1.44.1; intended engine 0.1.47.
- Model: Qwen3.8-Flash-Next UD Q4_K_XL.
- Reviewed invocation: local shell wrapper → PowerShell wrapper → `cmd /c 'UPDATE.bat < NUL'`. This is the legacy update entry point; it should not be conflated with a direct `strata.py update --no-control` invocation.

## Expected and actual behavior

**Expected:** if fetching the intended engine fails and the installed engine is retained, the final summary explicitly says the engine update failed or was incomplete, with the retained version. Automation should have a documented way to distinguish this from a successful engine upgrade.

**Actual:** the log contains the following output, in order (unrelated model-settings lines omitted):

```text
No ready-made engine for v0.1.47 (HTTP Error 404: Not Found): the latest release instead
Fetching the ready-made engine from the signed update feed ...
[!]  no engine from the update feed: {"schema_version": 1, "ok": false, ...
[!]  no ready-made engine at https://github.com/Niko1221/Strata/releases/latest/download/ (HTTP Error 404: Not Found)
[!]  could not update the engine: starting the installed 0.1.44.1
[ok] Strata is updated (engine 0.1.44.1). Start the model with START-HERE.bat when you want it.
```

The feed-error line above is abbreviated; the retained log output itself truncates that diagnostic, so it does not establish the underlying feed failure.

## Evidence and reproduction status

This is based on inspection of the retained local update log from 2026-10-21 and the scripts that produced it, not a fresh update run. The sequence appears twice in that log. Source inspection also finds the retained-engine warning and final success summary in [setup.py at the inspected commit](https://github.com/Niko1221/Strata/blob/011c9e600a93bbc9fd451c563501b5831c32bbca/setup.py).

The relevant scenario is a legacy update with engine 0.1.44.1 installed where fetching the intended newer engine fails. A controlled test that simulates that download failure would verify final messaging and exit status. Such a test has **not** been run for this correction; no exact upstream exit code is claimed.

## Earlier process-cleanup concern: unconfirmed

The earlier report also described leftover processes and a host freeze during this update window. The evidence reviewed does not establish that a particular surviving process belonged to the staged updater test, why cleanup failed, or how much memory it pinned.

The updater already calls `runtime.stop()` in a `finally` block and suppresses exceptions from that cleanup attempt: [default_test_start](https://github.com/Niko1221/Strata/blob/v0.2.2/strata_control/updater.py#L705-L766). That is a possible investigation point, not proof of a leak in this incident.

A process-cleanup report would need timestamped process identities and executable paths tied to the staged test, readiness/stop results, and measured memory counters. Until then, I withdraw the proposed identity-check bypass and rename-around-running-executable remedies. This issue now requests clearer update-result reporting only.

No site

Links install, modelos, releases.