morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[PR #2995] [CLOSED] fix(setup): detect existing Hopper install on Linux before reinstalling (#2270) #5546

New issue

Closed

opened 2026-10-31 01:07:29 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:07:29 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2995
Author: @hussnainahmedd
Created: 10/13/2026
Status: ❌ Closed

Base: main ← Head: fix/2270-hopper-linux-detect

📝 Commits (10+)

d6e3d3e fix(setup): detect existing Hopper install on Linux before reinstalling (#2270)
a4b25eb fix(setup): address review findings on Linux Hopper detection
45d475d Merge branch 'main' into fix/2270-hopper-linux-detect
a915644 fix(setup): validate Linux Hopper launchers before preferring them
a4b3425 Merge branch 'main' into fix/2270-hopper-linux-detect
887100a Merge branch 'main' into fix/2270-hopper-linux-detect
fc89396 fix(setup): share one Linux launcher order and probe it under the caller environment
45927ff Merge branch 'main' into fix/2270-hopper-linux-detect
1524ee9 fix(setup): bound the Linux linker probe with a hard deadline
45a68dd Merge remote-tracking branch 'upstream/main' into fix/2270-hopper-linux-detect

📊 Changes

12 files changed (+454 additions, -25 deletions)

View changed files

📝 docs/installation.md (+3 -2)
📝 src/application/Doctor.test.ts (+27 -0)
📝 src/application/DoctorDiagnostics.ts (+16 -4)
📝 src/application/LinuxHopper.ts (+33 -1)
📝 src/application/Setup.configuration.test.ts (+82 -0)
📝 src/application/Setup.fixture.ts (+2 -0)
📝 src/application/Setup.ts (+1 -0)
📝 src/application/SetupHost.ts (+2 -0)
📝 src/application/SetupPlan.ts (+18 -6)
📝 src/application/SetupTypes.ts (+7 -0)
📝 src/config.test.ts (+202 -2)
📝 src/config/parseConfig.ts (+61 -10)

📄 Description

Fixes #2270.

Problem

rea setup on Linux proposed (and with --yes --install-hopper, performed) a Hopper reinstall even when the user already had a working Hopper and had explicitly pointed REA at it via HOPPER_LAUNCHER_PATH.

Root cause: in discoverSetupState (src/application/SetupPlan.ts), linuxHopperRepairNeeded was true whenever the hopper-demo-runtime check failed or the hopper-version check failed at /opt/hopper/bin/Hopper. Both checks fail for legitimate existing installs that REA did not install itself:

hopper-version only accepts the pinned 6.4.2 demo-build SHA-256 digests, so a licensed build or a newer build (e.g. 6.5.0) fails the probe;
hopper-demo-runtime fails when the Xvfb private-display dependencies are absent, which is also true for licensed (non-demo) builds.

So a functioning, explicitly configured launcher still triggered the install_hopper plan.

Fix (setup/detection code only)

SetupInitialState gains hopperLauncherConfigured, set from HOPPER_LAUNCHER_PATH in systemSetupHost.initialSetupState (plumbed through runSetupWorkflow into discoverSetupState).
discoverSetupState no longer treats a failing version/demo-runtime probe as repair-needed when the launcher was explicitly configured: a configured, functioning launcher is the user's chosen provider and is treated as satisfied. rea doctor still reports the failing checks with their remediations.
The repair-install path is preserved for the REA-managed system install (/opt/hopper/bin/Hopper) when no launcher is configured.
Doctor discovery now also probes two more standard Linux launcher locations, /opt/hopper-v4/bin/hopper and /usr/bin/hopper, so installs there count as detected instead of prompting an install.

No sudo escalation behavior was added (REA deliberately avoids ambient sudo); the install plan still requires the existing user approval before any mutation.

Verification

New tests in src/application/Setup.configuration.test.ts (Hopper launcher detection (#2270)): configured launcher + failing demo-runtime check → no install_hopper action, 0 installs; configured launcher + failing version probe → no install_hopper action, 0 installs; unconfigured + failing version probe at /opt/hopper/bin/Hopper → repair install_hopper still proposed (regression guard).
New tests in src/application/Doctor.test.ts: /opt/hopper-v4/bin/hopper and /usr/bin/hopper are detected as the Hopper launcher.
Ran the touched-area suites (compiled with tsc, executed under plain node with a minimal vitest-compatible harness because this sandbox's rolldown native binding crashes on load, so vitest itself cannot run here):
- Setup.configuration.test 21 passed, Doctor.test 30 passed, Setup.planning.test 15 passed, Setup.recovery.test 12 passed, Setup.initialSnapshot.test 1 passed, config.test 41 passed, HopperProviderDiscovery.test 3 passed, SetupInstallFailure.test 2 passed, cliLogging.test 6 passed, setupEnvironment.test 5 passed — 136 passed, 0 failed.
tsc --noEmit on the repo tsconfig: 0 errors in any touched file (38 pre-existing errors elsewhere, all in src/browser/* playwright typings and one darwin boundary test, present on base and unrelated to this change; they stem from running the older pure-JS TS 5.9 here instead of the repo's pinned native TS 7.0.2).
npm run verify:module-boundaries: passed (1758 source files checked).
npm run verify:test-discovery: could not execute in this sandbox (it shells out to vitest, which SIGBUS-crashes on the broken rolldown native binding); no new test files were added — tests were added to two existing discovered files, so discovery output is unchanged.
oxlint on the 8 touched files: 0 errors, only the 4 warnings that already exist on base.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2995 **Author:** [@hussnainahmedd](https://github.com/hussnainahmedd) **Created:** 10/13/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/2270-hopper-linux-detect` --- ### 📝 Commits (10+) - [`d6e3d3e`](https://github.com/morluto/rea/commit/d6e3d3e1b431bbc76ad0804aa195042c63414142) fix(setup): detect existing Hopper install on Linux before reinstalling (#2270) - [`a4b25eb`](https://github.com/morluto/rea/commit/a4b25eb62f4b9635e49b51eb5965d4af98a3a2c9) fix(setup): address review findings on Linux Hopper detection - [`45d475d`](https://github.com/morluto/rea/commit/45d475dd64f930e7a650360def0b716433d9911c) Merge branch 'main' into fix/2270-hopper-linux-detect - [`a915644`](https://github.com/morluto/rea/commit/a9156440dd59e399fa9d53cab9ae372679239baf) fix(setup): validate Linux Hopper launchers before preferring them - [`a4b3425`](https://github.com/morluto/rea/commit/a4b3425fe9c9aed14eac0073b4d06973fa1c5439) Merge branch 'main' into fix/2270-hopper-linux-detect - [`887100a`](https://github.com/morluto/rea/commit/887100a0b46dd325911125e77d4fae4a1354e112) Merge branch 'main' into fix/2270-hopper-linux-detect - [`fc89396`](https://github.com/morluto/rea/commit/fc893960916ffddf1303ba451c7cd0b6b508056a) fix(setup): share one Linux launcher order and probe it under the caller environment - [`45927ff`](https://github.com/morluto/rea/commit/45927ffc82ecc160777b61fcfe6a7dacb754dfc4) Merge branch 'main' into fix/2270-hopper-linux-detect - [`1524ee9`](https://github.com/morluto/rea/commit/1524ee9e559b8be51d8540d643bcafd3dddbc6c7) fix(setup): bound the Linux linker probe with a hard deadline - [`45a68dd`](https://github.com/morluto/rea/commit/45a68dd6b73c9c94fbb378ddc6627c1de130fb12) Merge remote-tracking branch 'upstream/main' into fix/2270-hopper-linux-detect ### 📊 Changes **12 files changed** (+454 additions, -25 deletions) <details> <summary>View changed files</summary> 📝 `docs/installation.md` (+3 -2) 📝 `src/application/Doctor.test.ts` (+27 -0) 📝 `src/application/DoctorDiagnostics.ts` (+16 -4) 📝 `src/application/LinuxHopper.ts` (+33 -1) 📝 `src/application/Setup.configuration.test.ts` (+82 -0) 📝 `src/application/Setup.fixture.ts` (+2 -0) 📝 `src/application/Setup.ts` (+1 -0) 📝 `src/application/SetupHost.ts` (+2 -0) 📝 `src/application/SetupPlan.ts` (+18 -6) 📝 `src/application/SetupTypes.ts` (+7 -0) 📝 `src/config.test.ts` (+202 -2) 📝 `src/config/parseConfig.ts` (+61 -10) </details> ### 📄 Description Fixes #2270. ## Problem `rea setup` on Linux proposed (and with `--yes --install-hopper`, performed) a Hopper reinstall even when the user already had a working Hopper and had explicitly pointed REA at it via `HOPPER_LAUNCHER_PATH`. Root cause: in `discoverSetupState` (`src/application/SetupPlan.ts`), `linuxHopperRepairNeeded` was true whenever the `hopper-demo-runtime` check failed **or** the `hopper-version` check failed at `/opt/hopper/bin/Hopper`. Both checks fail for legitimate existing installs that REA did not install itself: - `hopper-version` only accepts the pinned 6.4.2 demo-build SHA-256 digests, so a licensed build or a newer build (e.g. 6.5.0) fails the probe; - `hopper-demo-runtime` fails when the Xvfb private-display dependencies are absent, which is also true for licensed (non-demo) builds. So a functioning, explicitly configured launcher still triggered the `install_hopper` plan. ## Fix (setup/detection code only) - `SetupInitialState` gains `hopperLauncherConfigured`, set from `HOPPER_LAUNCHER_PATH` in `systemSetupHost.initialSetupState` (plumbed through `runSetupWorkflow` into `discoverSetupState`). - `discoverSetupState` no longer treats a failing version/demo-runtime probe as repair-needed when the launcher was explicitly configured: a configured, functioning launcher is the user's chosen provider and is treated as satisfied. `rea doctor` still reports the failing checks with their remediations. - The repair-install path is preserved for the REA-managed system install (`/opt/hopper/bin/Hopper`) when no launcher is configured. - Doctor discovery now also probes two more standard Linux launcher locations, `/opt/hopper-v4/bin/hopper` and `/usr/bin/hopper`, so installs there count as detected instead of prompting an install. No sudo escalation behavior was added (REA deliberately avoids ambient `sudo`); the install plan still requires the existing user approval before any mutation. ## Verification - New tests in `src/application/Setup.configuration.test.ts` (`Hopper launcher detection (#2270)`): configured launcher + failing demo-runtime check → no `install_hopper` action, 0 installs; configured launcher + failing version probe → no `install_hopper` action, 0 installs; unconfigured + failing version probe at `/opt/hopper/bin/Hopper` → repair `install_hopper` still proposed (regression guard). - New tests in `src/application/Doctor.test.ts`: `/opt/hopper-v4/bin/hopper` and `/usr/bin/hopper` are detected as the Hopper launcher. - Ran the touched-area suites (compiled with `tsc`, executed under plain node with a minimal vitest-compatible harness because this sandbox's rolldown native binding crashes on load, so `vitest` itself cannot run here): - `Setup.configuration.test` 21 passed, `Doctor.test` 30 passed, `Setup.planning.test` 15 passed, `Setup.recovery.test` 12 passed, `Setup.initialSnapshot.test` 1 passed, `config.test` 41 passed, `HopperProviderDiscovery.test` 3 passed, `SetupInstallFailure.test` 2 passed, `cliLogging.test` 6 passed, `setupEnvironment.test` 5 passed — 136 passed, 0 failed. - `tsc --noEmit` on the repo tsconfig: 0 errors in any touched file (38 pre-existing errors elsewhere, all in `src/browser/*` playwright typings and one darwin boundary test, present on base and unrelated to this change; they stem from running the older pure-JS TS 5.9 here instead of the repo's pinned native TS 7.0.2). - `npm run verify:module-boundaries`: passed (1758 source files checked). - `npm run verify:test-discovery`: could not execute in this sandbox (it shells out to `vitest`, which SIGBUS-crashes on the broken rolldown native binding); no new test files were added — tests were added to two existing discovered files, so discovery output is unchanged. - `oxlint` on the 8 touched files: 0 errors, only the 4 warnings that already exist on base. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:07:29 +00:00

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-11-01 21:44:24 +00:00

[PR #5572] [CLOSED] fix(artifacts): keep DMG root observations when the image is already attached #6972

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#5546

No description provided.

Rows
Columns