Skip to content

fix(setup): recover incomplete self-contained Builder runtimes - #2449

Merged
hckrman101 merged 5 commits into
NotRexed:mainfrom
Arkex-ai:fix/windows-runtime-recovery
Nov 11, 2026
Merged

hckrman101 merged 5 commits into
NotRexed:mainfrom
Arkex-ai:fix/windows-runtime-recovery

Conversation

@Arkex-ai

@Arkex-ai Arkex-ai commented Nov 11, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Windows setup can accept a Builder executable and installed marker even when its private .NET runtime is missing. Incomplete installations now enter recovery, and incomplete staging stops before publication. The diagnostic keeps the affected paths and possible antivirus quarantine cause so retrying setup is actionable; the original cause in #2423 remains unconfirmed.

Technical changes

  • Use one startup-file check before installed reuse, staged publication and fast launch; reject missing/empty components and directories in place of files.
  • Preserve the accepted portable-home paths and rollback publication from feat(builder): add relocatable Windows portable installations #2367. Restore the quarantine/history hint, executable path and staging folder in the failure message.
  • Execute the actual recovery and portable-startup boundaries with authored files, including missing-runtime refusal followed by recovery. Keep checked downloads, explicit repair and the direct-game fallback.

Validation

Head 66f5ba8d8c89ba14330f8fbf118ff0d9b7ff5f47, rebased on main 6f4f28ac.

  • 56 real-Win32 file cases pass. Three independently removed entry guards are rejected by causal regressions; 14 portable-startup scenarios pass, including a missing runtime that cannot start a process and a restored runtime that can.
  • The complete Windows setup compiles and links with llvm-mingw. The refreshed native diagnostic below uses the actual readiness guard and message function with fictitious paths; no installation or game is involved.
  • Full Windows suite: 408 / 2 / 32 versus exact base 406 / 2 / 32 (passed / failed / skipped). Failing check and case identities match: NUP link tests and the VRAM-row fixture. The earlier portable fixture integration failure was corrected before this run. This is not an all-green local suite.
  • Current-head hosted CI is pending. Current Linux GPU/game, complete repair on the rebased source and the reporter's installation history are not validated. This checks the directory-based WPF startup contract, not every optional assembly or installed-file checksum.

Controlled incomplete-runtime diagnostic

Earlier-head validation

On 4171896d, all applicable hosted checks passed. A disposable controlled installation with EXE/marker present and coreclr.dll missing recovered through actual downloads, verified/unpacked pinned official v2.1.0, and ran its private .NET8.0.33 managed CLI help with exit0; original source files stayed unchanged. This was not the reporter's unconfirmed missing-file cause or a full game test, and has not been repeated on the rebased head.

Full suites on dead3fcd versus base 3e95ca68: Windows378/3/31 versus376/3/31; Linux385/2/25 versus385/2/23, with matching failing check identities. These are historical results, not checks of the current head.

Current-head workflow Result
Game-free source regressions Queued
Linux AppImage Running
PR title Queued
Windows builder Queued

@Joey-Magnus Joey-Magnus left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

builder_ready (setup.c:529) checks the 12 startup files, which matches the csproj (SelfContained=true, PublishSingleFile=false), and it's used in all three places that matter. The tests are thorough.

One fix before merge: the new error after unpacking (setup.c:776) drops the old antivirus hint and the folder path. Defender quarantining files is a known cause (the "Wacatac" worklist row), and in that case "Run the setup again" just loops. Please put the hint and the path back.

Validate required startup components before installed reuse, staged publication and fast launch. Exercise real Win32 file readiness and reject independent boundary-removal mutations without launching any Builder fixture.

Assisted-by: OpenAI Codex
Capture the native production error dialog using an authored missing-runtime fixture; distinguish it from complete installation validation.

Assisted-by: OpenAI Codex
Exercise the accepted home and publication helpers while checking the actual failure retains the antivirus hint and staging folder.

Assisted-by: OpenAI Codex
Refresh the authored native error-dialog capture and explain how the reported staging path helps investigate repeated quarantines.

Assisted-by: OpenAI Codex
Include the production readiness helper and authored required files; verify an incomplete portable runtime never starts a process and recovers once restored.

Assisted-by: OpenAI Codex
@Arkex-ai
Arkex-ai force-pushed the fix/windows-runtime-recovery branch from 4171896 to 66f5ba8 Compare November 11, 2026 22:03
@Arkex-ai

Copy link
Copy Markdown
Contributor Author

Restored the quarantine/history hint, affected executable and staging-folder paths, and refreshed the controlled native screenshot.

Rebased on 6f4f28ac, preserving #2367's portable-home paths and rollback publication. That integration also needed the portable startup fixture to include the production readiness helper and authored runtime files; its 14 scenarios now cover refusing an incomplete runtime and launching after restoration. The 56 file cases, three guard mutations and complete setup link pass. Full-suite comparison and current-head CI status are recorded in the updated description; the original reporter's cause remains unconfirmed.

@hckrman101
hckrman101 merged commit 2dfe901 into NotRexed:main Nov 11, 2026
15 checks passed
madebyjordan added a commit to madebyjordan/Longshot that referenced this pull request Nov 12, 2026
…ry button can be pressed

scripts/launcher/dummy.ps1 makes a world afresh at each start of scripts/launcher/live.ps1 (build/launcher/live): the
test rig's releases (rig.py) served on 127.0.0.1, v2.1.0 installed with the real setup beside it, a game folder holding
v2.1.0 whose game is a stand-in that says "Play works" (dummygame.c), and an empty game file chosen for Build. The
builders' python.exe is the rig's stand-in for make_game.py, so Update installs v2.2.0's builder from that server and
"builds" the folder in about 10 seconds; -Fail makes every build stop half way.

- Builders.DummyReleases (HOOKSHOT_DUMMY_RELEASES, development only): a release's builder is installed from
  <url>list-<tag>.txt, and the launcher's own downloads are refused (a first builder from GitHub, AMD's FSR runtime).
- rig.py: its releases and v2.1.0 have the runtime files the setup checks since NotRexed#2449 (builder_ready), without which
  the setup refused every made-up builder; tests/builder_launcher/rig/run.ps1's setup checks pass again.
- fakepy.c: FAKE_GAME_EXE, the game a build from game files makes.

Checked off-screen against the made-up releases: Update (v2.1.0 -> v2.2.0, builder installed from the local server),
Build (a new folder at v2.2.0 with the stand-in game) and a failing Update (the folder left at v2.1.0) all end as they
should, the real %LOCALAPPDATA%\HookshotBuilder is untouched, and no stand-in is left running.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Fanatrick pushed a commit to Fanatrick/Hookshot that referenced this pull request Nov 12, 2026
198 commits behind: the portable installations (NotRexed#2367), the update guard for a
folder newer than the latest release (NotRexed#2519) and the builder's update fixes
since (NotRexed#2141, NotRexed#2449, NotRexed#2528) all touch the files this branch changes.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DBGH7x7hn8ibuEU45oPKo2
dazemc added a commit to dazemc/Hookshot-rs that referenced this pull request Nov 13, 2026
…or launching it

Windows setup accepted a version folder with HookshotBuilder.exe and its
installed marker even when the Flutter runtime, its data folder or the Rust
engine was missing, so an incomplete extraction or an antivirus quarantine
was reused, published, or launched as if it were complete.

Ported from upstream 2dfe901 (NotRexed#2449) to this fork's Flutter package: one
builder_ready check (the exe plus flutter_windows.dll, data/icudtl.dat,
data/app.so, hookshot_engine.exe and hookshot_engine.dll, each a non-empty
file) now guards installed reuse, staged publication and fast launch. The
staged failure names the quarantine/history and says no complete
installation was published. The portable-home machinery of upstream NotRexed#2367
is not part of this change.

Tests: builder/rust/tests/setup_readiness.rs cuts builder_ready out of the
production source and runs it against authored Win32 file-attribute
doubles (complete package, each missing component, empty file, folder in
place of a file, empty or missing exe, no folder to anchor names), plus
source checks for the three call sites and the diagnostic. Game-free; no
Windows executable, installer or game data.

Assisted-by: opencode (DeepSeek V4.1 Flash 1017)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants