morluto/rea

Fork 0

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

[GH-ISSUE #8503] [Bug] Hopper metadata and macOS download paths discard HTTP status and URL #6630

New issue

Closed

opened 2026-11-01 21:12:47 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:12:47 +00:00

Owner

Originally created by @morluto on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8503

Originally assigned to: @kaoru0822-kitauji on GitHub.

Before submitting

Searched open and closed issues for related reports.
Removed credentials, private paths, and sensitive target data.

Area

Setup, packaging, or upgrade

Observed behavior

Hopper download callers discard HTTP failure facts that the transport has already observed. Confirmed cases include the macOS installer (feed and package), the Linux publisher release feed, and the Linux publisher public-key request. HTTP 404 and 503 become indistinguishable within each of these paths. The failed URL is also absent.

Reproduction

Executed the current source systemSetupHost(...).installHopper(false) twice with a Darwin doctor host and controlled fetch responses: return the real captured release feed as HTTP 200 for the first request, then return 404 or 503 for the selected DMG request. Each run returned the result below. Closed each setup host afterward; no package was installed.

These are production-boundary reproductions with injected HTTP failures, not reports that the live DMG endpoint returned those statuses. The live download succeeded.

The pattern sweep also executed LinuxHopperPublisher.currentRelease("deb") with 404/503 feed responses, verifyArchive("deb", capturedRelease, downloadedOfficialDeb) with 404/503 key responses, and the macOS setup host with 404/503 feed responses. Each discarded the observed status. These calls used current source on macOS; no Linux package manager or Hopper application ran.

Expected behavior

Retain the failed stage, requested URL and observed HTTP status through the public setup result. Keep timeouts and network failures distinct when known. Recovery should allow callers to distinguish a missing release from a transient service failure.

Impact and scope

Deterministic for both injected statuses in each exercised branch. Users receive the same advice for distinct failures and cannot identify the failing request from the returned diagnostic.

REA version

Source 3842809c371a59609f576a9db8f9c492a3f071e6; relevant files unchanged at 53363166f068a21f00a605187e1c3af428aa7d5d.

Runtime and platform

Darwin arm64, Node 24.22.1, Hopper 6.6.1 release feed. No real HTTP outage or full provider execution was reproduced.

Target and artifact context

Official macOS Hopper package download; no analysis target.

Interface

Package or setup

Earliest failure stage

Transport or result projection

Relevant output or evidence

Both injected statuses produce exactly:

{
  "status": "failed",
  "code": "download_failed",
  "remediation": "REA could not download or unpack the official Hopper package. Check network and filesystem access, then retry setup."
}

Additional confirmed branches:

Path	Returned result for either HTTP 404 or 503
macOS feed	Same generic `download_failed` setup result above
Linux publisher feed	`release_metadata`: `The official Hopper release feed is unavailable.`
Linux publisher public key	`verification_unavailable`: `The official Hopper public key is unavailable.`

Positive control: installLinuxHopper with the same controlled package responses does retain Package download returned HTTP 404/503 in operationFailure. That fixed branch shows this is not a universal downloader failure. An additional ordinary-launch package-verification branch at LinuxHopperPublisher.ts:535 also drops the status by source inspection; it was not separately executed.

HopperDownload.ts captures httpStatus. MacHopper.ts:155 returns only reason: "download"; its download host contract omits the status. The setup adapter therefore cannot report it.

Analysis or suspected cause

The shared transport facts are lost in multiple consumer projections: macOS installer lines 147/155 and Linux publisher feed/key branches at lines 127/191. Carry a typed download failure through these adapters and the final setup result, rather than repairing one platform's message at a time. Keep HTTP failure, timeout, invalid package, and cleanup failure distinct.

Related: #7182/#7183 fixed Linux package HTTP status handling; #7077 covers the Linux timeout and vendor hash mismatch. Those reports do not resolve the macOS branch.

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8503 Originally assigned to: @kaoru0822-kitauji on GitHub. ### Before submitting - [x] Searched open and closed issues for related reports. - [x] Removed credentials, private paths, and sensitive target data. ### Area Setup, packaging, or upgrade ### Observed behavior Hopper download callers discard HTTP failure facts that the transport has already observed. Confirmed cases include the macOS installer (feed and package), the Linux publisher release feed, and the Linux publisher public-key request. HTTP **404** and **503** become indistinguishable within each of these paths. The failed URL is also absent. ### Reproduction Executed the current source `systemSetupHost(...).installHopper(false)` twice with a Darwin doctor host and controlled fetch responses: return the real captured release feed as HTTP 200 for the first request, then return 404 or 503 for the selected DMG request. Each run returned the result below. Closed each setup host afterward; no package was installed. These are production-boundary reproductions with injected HTTP failures, not reports that the live DMG endpoint returned those statuses. The live download succeeded. The pattern sweep also executed `LinuxHopperPublisher.currentRelease("deb")` with 404/503 feed responses, `verifyArchive("deb", capturedRelease, downloadedOfficialDeb)` with 404/503 key responses, and the macOS setup host with 404/503 feed responses. Each discarded the observed status. These calls used current source on macOS; no Linux package manager or Hopper application ran. ### Expected behavior Retain the failed stage, requested URL and observed HTTP status through the public setup result. Keep timeouts and network failures distinct when known. Recovery should allow callers to distinguish a missing release from a transient service failure. ### Impact and scope Deterministic for both injected statuses in each exercised branch. Users receive the same advice for distinct failures and cannot identify the failing request from the returned diagnostic. ### REA version Source `3842809c371a59609f576a9db8f9c492a3f071e6`; relevant files unchanged at `53363166f068a21f00a605187e1c3af428aa7d5d`. ### Runtime and platform Darwin arm64, Node 24.22.1, Hopper 6.6.1 release feed. No real HTTP outage or full provider execution was reproduced. ### Target and artifact context Official macOS Hopper package download; no analysis target. ### Interface Package or setup ### Earliest failure stage Transport or result projection ### Relevant output or evidence Both injected statuses produce exactly: ```json { "status": "failed", "code": "download_failed", "remediation": "REA could not download or unpack the official Hopper package. Check network and filesystem access, then retry setup." } ``` Additional confirmed branches: | Path | Returned result for either HTTP 404 or 503 | | --- | --- | | macOS feed | Same generic `download_failed` setup result above | | Linux publisher feed | `release_metadata`: `The official Hopper release feed is unavailable.` | | Linux publisher public key | `verification_unavailable`: `The official Hopper public key is unavailable.` | Positive control: `installLinuxHopper` with the same controlled package responses **does** retain `Package download returned HTTP 404/503` in `operationFailure`. That fixed branch shows this is not a universal downloader failure. An additional ordinary-launch package-verification branch at `LinuxHopperPublisher.ts:535` also drops the status by source inspection; it was not separately executed. [`HopperDownload.ts`](https://github.com/morluto/rea/blob/3842809c371a59609f576a9db8f9c492a3f071e6/src/application/HopperDownload.ts) captures `httpStatus`. [`MacHopper.ts:155`](https://github.com/morluto/rea/blob/3842809c371a59609f576a9db8f9c492a3f071e6/src/application/MacHopper.ts#L155) returns only `reason: "download"`; its download host contract omits the status. The setup adapter therefore cannot report it. ### Analysis or suspected cause The shared transport facts are lost in multiple consumer projections: macOS installer lines 147/155 and Linux publisher feed/key branches at lines 127/191. Carry a typed download failure through these adapters and the final setup result, rather than repairing one platform's message at a time. Keep HTTP failure, timeout, invalid package, and cleanup failure distinct. Related: #7182/#7183 fixed Linux package HTTP status handling; #7077 covers the Linux timeout and vendor hash mismatch. Those reports do not resolve the macOS branch.

bsakaguchi

2026-11-01 21:12:47 +00:00

closed this issue
added the
bug

triage
labels

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#6630

No description provided.

Rows
Columns