Home

dev / openkara

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

#395 Runtime worker stages its candidate before the probe, so a probe-failed install is promoted unprobed on the next launch

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 L156-198 (run_worker), interacting with src-tauri/src/separator/activation.rs L569-573 and src-tauri/src/app_runtime.rs L67-72.

What goes wrong

The bootstrap worker stages its install as the next-launch candidate before probing that the library actually loads:

// L156-159
// Keep the verified install reachable after a worker kill. Startup can
// promote this candidate without downloading the archive again.
runtime_bootstrap::stage_candidate(&request.app_data_dir, &installed.record.artifact_id)?;
// ... probe happens later, at L185
crate::separator::model::ensure_runtime_loaded_from_path(&installed.library_path)?;

When the probe fails (or the worker is killed by the parent's post-download watchdog mid-probe), the worker exits with an error — but slots.candidate keeps pointing at the never-proven install.

Per ADR-0023, startup treats the worker probe as authoritative: resolve_and_load(CandidateProof::WorkerProbe) promotes a staged candidate and acknowledges it without loading it (activation.rs L569-573). So on the next launch the probe-failed install is promoted straight to active, activation_pending is cleared, and the first real load attempt happens later — burning the activation-attempt rollback budget on an artifact that was never proven, exactly the situation the worker probe exists to prevent.

Effect

A single failed probe (bad download server output, antivirus interference, an incompatible library) converts into a bad active runtime at next startup instead of being discarded. Recovery then depends on the in-process load failure/rollback path, which is strictly worse: it can delete the failed generation and the rollback may land on no previous generation at all, leaving the user with no runtime.

Suggested resolution

Stage the candidate only after the probe succeeds (the WorkerProbe acknowledgement then holds by construction). The pre-probe staging exists so a killed worker's verified download is not re-downloaded — that is already covered by the verified archive cache (runtime-download-cache/) and by the install-directory reuse check, so moving the staging point after the probe does not reintroduce a re-download.

Sign in to comment.

Linked pull requests

No linked pull requests yet.