Home

dev / openkara

publicthedavidweng/OpenKara· sync paused
Code Branches Pull requestsIssuesInsights
main
Home Code PRsIssues

#394 Runtime install reuse ignores the target archive digest, so a same-id catalog update never installs

closed

Opened by dev · yesterday

devopened this issueAuthor· yesterday

Line references are pinned to main at 992e7d1d.

Where

src-tauri/src/commands/runtime_worker.rs L305-317, inside install_runtime_with_verified_archive_cache.

What goes wrong

Before downloading, the worker reuses an existing install for the target artifact id when its files verify against its own record.json:

// L305-310
if let Some(existing) = runtime_bootstrap::installed_runtime(app_data_dir, &runtime.artifact_id)
{
    if runtime_bootstrap::verify_runtime_files(&existing)? {
        progress(RuntimeWorkerProgress::phase(RuntimeWorkerPhase::Installing));
        return Ok(existing);
    }

verify_runtime_files checks the installed files against the digests recorded at install time — it proves the install is intact, not that it is the artifact the target catalog entry describes. The record's archive_sha256 is never compared against the target runtime.archive_digest.

Catalog generation 13 republished all six reduced runtimes under the same artifact ids with new digests (e.g. onnxruntime-1.27.1-openkara-x86_64-pc-windows-msvc-cpu-reduced: f127d8aa… → 3146e4fd…). For any user with an intact gen-12 install, the gen-13 update download short-circuits on the reuse check and returns the gen-12 install.

Effect

An infinite "update available but never installs" loop for healthy users: check_runtime_updates compares the installed record's archive_sha256 against the catalog digest and keeps reporting UpdateAvailable, while every download attempt "succeeds" by re-staging the already-installed gen-12 bytes. The gen-13 static-CRT Windows runtimes (#284, #363) can never reach users who already have gen-12 installed.

Suggested resolution

Reuse requires digest equality: only return an existing install when record.archive_sha256 matches the target catalog entry's archive_digest (in addition to file verification). A same-id install with a different digest must not be deleted in place either — on Windows it may be the currently loaded runtime, whose files cannot be removed — so the replacement generation needs to install alongside it (digest-qualified install directory) and go through the normal candidate staging flow.

Sign in to comment.

Linked pull requests

No linked pull requests yet.