fix(builder): the first page offers the update again after one that stopped (#2129) #2141

Merged

jarynclouatre merged 1 commit from fix/builder-update-back into main

2026-11-11 20:36:00 +00:00

jarynclouatre commented

2026-11-11 04:45:08 +00:00

(Migrated from github.com)

Part of #2129. After an update that stopped, Back left the builder on a first page it couldn't use: a grey "Build the game" with no game files, until the app was closed and opened again.

The first page's button is left alone while an update runs (RefreshMode returns at once), and nothing let that go when the update stopped or was cancelled. A start with --update also goes past the first page's setup, so the game files, the saved choices and the release check never ran. Back and a cancelled run now go through one function: when an update is what stopped, it lets the button go, and if the page was never set up it does what the start does, for the update's folder rather than the last build's. A build that stopped goes back as before. The Python builder has the same flow and the same change.

The report also says the update itself failed several times. It gives no error text, so that part isn't addressed here.

Testing

Windows 11, the WPF builder built from this branch and from main, started with --update on a stand-in game folder (v2.0.14, HOOKSHOT_LATEST_TAG=v9.9.9) so the update stops at once, then Back pressed. On main the first page shows a grey "Build the game". With this change it shows "Update available" and an enabled Update button.
Linux: tests/test_builder_update_back.py passes (7 tests) and fails on main (5 failures, 1 error). It runs the Python builder's own functions on a stand-in window and reads the C# for the same shape.
The Python builder's window wasn't opened (no PySide6 here).

Part of #2129. After an update that stopped, Back left the builder on a first page it couldn't use: a grey "Build the game" with no game files, until the app was closed and opened again. The first page's button is left alone while an update runs (`RefreshMode` returns at once), and nothing let that go when the update stopped or was cancelled. A start with `--update` also goes past the first page's setup, so the game files, the saved choices and the release check never ran. Back and a cancelled run now go through one function: when an update is what stopped, it lets the button go, and if the page was never set up it does what the start does, for the update's folder rather than the last build's. A build that stopped goes back as before. The Python builder has the same flow and the same change. The report also says the update itself failed several times. It gives no error text, so that part isn't addressed here. **Testing** - Windows 11, the WPF builder built from this branch and from main, started with `--update` on a stand-in game folder (v2.0.14, `HOOKSHOT_LATEST_TAG=v9.9.9`) so the update stops at once, then Back pressed. On main the first page shows a grey "Build the game". With this change it shows "Update available" and an enabled Update button. - Linux: `tests/test_builder_update_back.py` passes (7 tests) and fails on main (5 failures, 1 error). It runs the Python builder's own functions on a stand-in window and reads the C# for the same shape. - The Python builder's window wasn't opened (no PySide6 here).

Joey-Magnus (Migrated from github.com) approved these changes

2026-11-11 20:06:49 +00:00

Joey-Magnus (Migrated from github.com) left a comment

This looks right to me. I traced the flows in builder/HookshotBuilder/MainWindow.xaml.cs. RefreshMode returns early while updating is set (line 177). BeginUpdate sets it, and only Run(keepRows: false) cleared it before. So after a stopped update the first page kept its old button, and after a --update or --launch start the page had never been set up at all. Routing Back and the cancelled path through ToFiles() (line 133) fixes both cases:

When the page was already set up, it clears updating and calls Refresh().
When it wasn't, it runs the same setup steps as Start(), and it keeps the update's folder instead of the last build's.

The download-failure path (DownloadFailed → ShowProblem → Back) goes through ToFiles() too, so that case is covered. The Python builder's back() and found_go() mirror it, including the folder being kept.

tests/test_builder_update_back.py passes here, as do the other builder_ checks I could run (the two dotnet ones were skipped on this machine). CI is green.

One thing to consider, not blocking: in ToFiles() the page is shown and updating is cleared before await Task.Run(Finder.FindDumps). During that wait the player could change the output folder or the files, and ApplySettings() would then overwrite those changes. The button is still grey during the wait, so this is cosmetic. If you want to close the gap, call ShowPage(FilesPage) after the setup.

This looks right to me. I traced the flows in `builder/HookshotBuilder/MainWindow.xaml.cs`. `RefreshMode` returns early while `updating` is set (line 177). `BeginUpdate` sets it, and only `Run(keepRows: false)` cleared it before. So after a stopped update the first page kept its old button, and after a `--update` or `--launch` start the page had never been set up at all. Routing Back and the cancelled path through `ToFiles()` (line 133) fixes both cases: - When the page was already set up, it clears `updating` and calls `Refresh()`. - When it wasn't, it runs the same setup steps as `Start()`, and it keeps the update's folder instead of the last build's. The download-failure path (`DownloadFailed` → `ShowProblem` → Back) goes through `ToFiles()` too, so that case is covered. The Python builder's `back()` and `found_go()` mirror it, including the folder being kept. `tests/test_builder_update_back.py` passes here, as do the other `builder_` checks I could run (the two `dotnet` ones were skipped on this machine). CI is green. One thing to consider, not blocking: in `ToFiles()` the page is shown and `updating` is cleared before `await Task.Run(Finder.FindDumps)`. During that wait the player could change the output folder or the files, and `ApplySettings()` would then overwrite those changes. The button is still grey during the wait, so this is cosmetic. If you want to close the gap, call `ShowPage(FilesPage)` after the setup.