[PR #4719] fix(setup): bound Hopper downloads by idle time instead of total duration #6369

New issue

Open

opened 2026-10-31 01:13:56 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/4719
Author: @maweis1981
Created: 10/17/2026
Status: 🔄 Open

Base: main ← Head: fix/hopper-download-idle-timeout

📝 Commits (1)

790b32a fix(setup): bound Hopper downloads by idle time instead of total duration

📊 Changes

2 files changed (+132 additions, -32 deletions)

View changed files

➕ src/application/HopperDownload.test.ts (+68 -0)
📝 src/application/HopperDownload.ts (+64 -32)

📄 Description

Problem

rea setup --install-hopper reported download_failed on slow links. downloadHopperPackage aborted the entire request after 120 s total, and the macOS DMG (~35 MB) needs far longer when the vendor server delivers around 9 KB/s. That rate was measured with the installer's own request headers, which hopperapp.com accepts (HTTP 200). In practice, setup failed every time even though bytes were still arriving.

Change

Replace the 120 s total deadline with a 120 s idle deadline. The timer resets after the response headers arrive and after each body chunk. The download aborts only when the vendor stops delivering bytes.
The caller signal and the 100 MB response bound are unchanged.
The macOS and Linux installers both use this function, so both get the fix.

Validation

Added src/application/HopperDownload.test.ts, which runs against a local HTTP server:
- a trickled body whose total time exceeds the idle limit completes;
- a body that stalls is aborted with an idle-timeout error.
When the old total-deadline behavior is restored, the slow-download test fails.
npm run test:local -- src/application/{HopperDownload,MacHopper,LinuxHopper}.test.ts: 40 tests pass.
npm run check:fast passes.

Real-provider scope

A run of installMacHopper from the built dist/ against hopperapp.com on macOS (arm64) is still in progress; it takes about an hour because of the vendor's download speed. The Linux package download was not exercised against the vendor.

🤖 Generated with Claude Code

_{🔄 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/4719 **Author:** [@maweis1981](https://github.com/maweis1981) **Created:** 10/17/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/hopper-download-idle-timeout` --- ### 📝 Commits (1) - [`790b32a`](https://github.com/morluto/rea/commit/790b32ac5b04564bcaac9cf39d24f7f4a25054d3) fix(setup): bound Hopper downloads by idle time instead of total duration ### 📊 Changes **2 files changed** (+132 additions, -32 deletions) <details> <summary>View changed files</summary> ➕ `src/application/HopperDownload.test.ts` (+68 -0) 📝 `src/application/HopperDownload.ts` (+64 -32) </details> ### 📄 Description ## Problem `rea setup --install-hopper` reported `download_failed` on slow links. `downloadHopperPackage` aborted the entire request after 120 s total, and the macOS DMG (~35 MB) needs far longer when the vendor server delivers around 9 KB/s. That rate was measured with the installer's own request headers, which hopperapp.com accepts (HTTP 200). In practice, setup failed every time even though bytes were still arriving. ## Change - Replace the 120 s total deadline with a 120 s **idle** deadline. The timer resets after the response headers arrive and after each body chunk. The download aborts only when the vendor stops delivering bytes. - The caller `signal` and the 100 MB response bound are unchanged. - The macOS and Linux installers both use this function, so both get the fix. ## Validation - Added `src/application/HopperDownload.test.ts`, which runs against a local HTTP server: - a trickled body whose total time exceeds the idle limit completes; - a body that stalls is aborted with an idle-timeout error. - When the old total-deadline behavior is restored, the slow-download test fails. - `npm run test:local -- src/application/{HopperDownload,MacHopper,LinuxHopper}.test.ts`: 40 tests pass. - `npm run check:fast` passes. ## Real-provider scope A run of `installMacHopper` from the built `dist/` against hopperapp.com on macOS (arm64) is still in progress; it takes about an hour because of the vendor's download speed. The Linux package download was not exercised against the vendor. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

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

bsakaguchi referenced this issue

2026-11-01 21:11:07 +00:00

[GH-ISSUE #5654] [Tracker] Open PRs that can't merge yet: conflicts and red CI (October 2026) #3425

bsakaguchi referenced this issue

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

[PR #6369] [CLOSED] fix(gdb): reject queued commands once their session is closing #7316

bsakaguchi referenced this issue

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