[GH-ISSUE #8008] [Bug] Linux demo-dialog watcher reports a publisher-verification failure when no registration dialog appears #4657

New issue

Closed

opened 2026-10-31 00:52:05 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:52:05 +00:00

Owner

Originally created by @CharlesXu on GitHub (Oct 29, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8008

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Provider or capability discovery

Observed behavior

On Linux, scripts/hopper-demo-x11.py waits at most 10 seconds (hardcoded deadline = time.monotonic() + 10) for either the bridge socket or Hopper's first-run registration dialog. When neither is observed it raises, and in 6.8.0 the caller sees a launch rejection:

{"code":"provider_unavailable","category":"unavailable",
 "message":"The selected Hopper launcher does not match an authenticated cached release or the official current Linux demo.",
 "details":{"stage":"launch","provider_state":"unknown",
  "launch_rejection":{"boundary":"publisher_verification","reason":"unsupported_hopper_build"}}}

Two different situations collapse into that single rejection: the launcher was not admitted, and the launcher was admitted but never presents a dialog to dismiss. In the second case the boundary, the reason and the message above all name a stage that already succeeded.

Source-derived: on Linux launchMode is set to verified_linux_demo unconditionally in HopperProvider.js, so every Linux launch is funnelled through this watcher regardless of launcher provenance. The watcher is the only component in that path that could distinguish "not admitted" from "nothing to click", and it currently does not.

Observed once on a Linux host with a launcher that had already passed launch-time authentication: the run failed after roughly ten seconds with the rejection above, and the same launcher and target completed when only the watcher's wait was widened. Target, host and result details are withheld deliberately; the mechanism described here comes from the source, not from that single observation.

Reproduction

Linux host with a Hopper launcher that has already passed launch-time authentication.
Run rea analyze <target> --provider hopper --format json.
The watcher's fixed deadline expires and the run fails with boundary: publisher_verification / reason: unsupported_hopper_build.

Reproduced on one host, and the failure ended when the wait was widened. Hosts where the registration dialog does appear were not tested, so frequency and platform spread are unknown.

Expected behavior

Once launcher authentication has succeeded and the bridge socket comes up, an absent first-run dialog should not be reported as a launcher-verification failure.
Absence of a dialog should be distinguishable from a dialog that appears but cannot be dismissed, e.g. separate reason codes rather than one unsupported_demo_dialog.
The 10-second window should be configurable rather than hardcoded, since unattended and CI hosts can need longer (see the "Hopper in CI" guidance in docs/installation.md).

Impact and scope

Misattributes the failure to launcher verification, so debugging starts in a subsystem that already passed; the real cause (a fixed wait) is invisible in the error.
Source-derived: the mapping from "no dialog observed" to the publisher-verification boundary is the misleading part. Other paths that reach the same rejection were not enumerated.
No admission-policy change is requested in this report.

REA version

6.8.0 (rea-agents)

Runtime and platform

Linux x86_64; Node 24.x; Hopper 6.x. Further host detail withheld.

Target and artifact context

Not applicable to this report; target details withheld.

Interface

CLI

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Launch rejection (paths redacted):

{"code":"provider_unavailable",
 "details":{"stage":"launch","provider_state":"unknown",
  "launch_rejection":{"boundary":"publisher_verification","reason":"unsupported_hopper_build"}},
 "remediation":{"action":"Check the Hopper launcher and target details, then retry opening the target."}}

Source references: scripts/hopper-demo-x11.py (fixed 10-second deadline; raises when neither socket nor dialog is observed), HopperProvider.js (launchMode = "verified_linux_demo" on Linux), src/application/LinuxHopperPublisher.ts (#inspectLauncher acceptance paths).

Originally created by @CharlesXu on GitHub (Oct 29, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8008 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Provider or capability discovery ### Observed behavior On Linux, `scripts/hopper-demo-x11.py` waits at most 10 seconds (hardcoded `deadline = time.monotonic() + 10`) for either the bridge socket or Hopper's first-run registration dialog. When neither is observed it raises, and in 6.8.0 the caller sees a launch rejection: ```json {"code":"provider_unavailable","category":"unavailable", "message":"The selected Hopper launcher does not match an authenticated cached release or the official current Linux demo.", "details":{"stage":"launch","provider_state":"unknown", "launch_rejection":{"boundary":"publisher_verification","reason":"unsupported_hopper_build"}}} ``` Two different situations collapse into that single rejection: the launcher was not admitted, and the launcher was admitted but never presents a dialog to dismiss. In the second case the boundary, the reason and the message above all name a stage that already succeeded. Source-derived: on Linux `launchMode` is set to `verified_linux_demo` unconditionally in `HopperProvider.js`, so every Linux launch is funnelled through this watcher regardless of launcher provenance. The watcher is the only component in that path that could distinguish "not admitted" from "nothing to click", and it currently does not. Observed once on a Linux host with a launcher that had already passed launch-time authentication: the run failed after roughly ten seconds with the rejection above, and the same launcher and target completed when only the watcher's wait was widened. Target, host and result details are withheld deliberately; the mechanism described here comes from the source, not from that single observation. ### Reproduction 1. Linux host with a Hopper launcher that has already passed launch-time authentication. 2. Run `rea analyze <target> --provider hopper --format json`. 3. The watcher's fixed deadline expires and the run fails with `boundary: publisher_verification` / `reason: unsupported_hopper_build`. Reproduced on one host, and the failure ended when the wait was widened. Hosts where the registration dialog does appear were not tested, so frequency and platform spread are unknown. ### Expected behavior - Once launcher authentication has succeeded and the bridge socket comes up, an absent first-run dialog should not be reported as a launcher-verification failure. - Absence of a dialog should be distinguishable from a dialog that appears but cannot be dismissed, e.g. separate reason codes rather than one `unsupported_demo_dialog`. - The 10-second window should be configurable rather than hardcoded, since unattended and CI hosts can need longer (see the "Hopper in CI" guidance in `docs/installation.md`). ### Impact and scope - Misattributes the failure to launcher verification, so debugging starts in a subsystem that already passed; the real cause (a fixed wait) is invisible in the error. - Source-derived: the mapping from "no dialog observed" to the publisher-verification boundary is the misleading part. Other paths that reach the same rejection were not enumerated. - No admission-policy change is requested in this report. ### REA version 6.8.0 (rea-agents) ### Runtime and platform Linux x86_64; Node 24.x; Hopper 6.x. Further host detail withheld. ### Target and artifact context Not applicable to this report; target details withheld. ### Interface CLI ### Earliest failure stage Setup or provider admission ### Relevant output or evidence Launch rejection (paths redacted): ```json {"code":"provider_unavailable", "details":{"stage":"launch","provider_state":"unknown", "launch_rejection":{"boundary":"publisher_verification","reason":"unsupported_hopper_build"}}, "remediation":{"action":"Check the Hopper launcher and target details, then retry opening the target."}} ``` Source references: `scripts/hopper-demo-x11.py` (fixed 10-second deadline; raises when neither socket nor dialog is observed), `HopperProvider.js` (`launchMode = "verified_linux_demo"` on Linux), `src/application/LinuxHopperPublisher.ts` (`#inspectLauncher` acceptance paths).

bsakaguchi closed this issue

2026-10-31 00:52:05 +00:00

bsakaguchi referenced this issue

2026-10-31 01:13:48 +00:00

[PR #4671] [CLOSED] fix(ghidra): try keg-only Homebrew JDK when PATH java cannot run #6355