[PR #7032] [MERGED] fix(setup): materialize the pinned package-runner cache before the first client start #7588

Closed
opened 2026-11-03 13:38:55 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/7032
Author: @wxj006007
Created: 10/24/2026
Status: ✅ Merged
Merged: 10/24/2026
Merged by: @morluto

Base: main ← Head: fix/setup-prewarm-pinned-runner


📝 Commits (3)

  • c7b552a fix(setup): materialize the pinned package-runner cache before the first client start
  • 88dd2c1 fix(setup): gate prewarm to applied registrations and supervise the runner tree
  • 92a86f9 fix(setup): forward terminal interrupts to the detached prewarm runner

📊 Changes

8 files changed (+680 additions, -1 deletions)

View changed files

📝 docs/installation.md (+7 -0)
📝 src/application/Setup.ts (+30 -0)
📝 src/application/SetupHost.ts (+12 -1)
➕ src/application/SetupRegistrationPrewarm.test.ts (+181 -0)
➕ src/application/SetupRegistrationPrewarm.ts (+207 -0)
📝 src/application/SetupTypes.ts (+8 -0)
📝 src/cli/interactiveSetup.ts (+2 -0)
➕ tests/boundary/filesystem/setupRegistrationPrewarm.test.ts (+233 -0)

📄 Description

Fixes #7027

Problem

Package runners key their package cache by the requested spec, so the _npx entry installed for the rea-agents@latest invocation that ran setup cannot serve the pinned rea-agents@<version> registration that setup writes. The first client start after setup installs that entry inside the client's MCP startup deadline; one client log recorded three consecutive connection timed out after 30000ms failures, and a controlled cold install with every tarball already in _cacache took 22 s on the same machine (issue has the full measurements).

Change

  • src/application/SetupRegistrationPrewarm.ts: derives a cache-materializing variant of the registration command (same spec, terminating --version subcommand) and materializes it once through execFileOutput with a bounded timeout. Direct launcher registrations return skipped. The spawn runs in a neutral working directory: inside a REA source checkout the package runner resolves the local project instead of the published entry and the warm-up fails.
  • SetupHost.systemSetupHost exposes this as the optional host capability prewarmRegistrationRunner; runSetupWorkflow invokes it after client configuration and skill installation succeed, before the final doctor summary. The step is best-effort and non-fatal: SetupResult carries an optional prewarm summary, interactive output prints a warning line on failure, and hosts without the capability are unaffected.
  • docs/installation.md: documents why setup performs this step and what happens when it cannot run.

Tests

  • src/application/SetupRegistrationPrewarm.test.ts (services): command derivation for npx/bunx/Windows-wrapped and direct launchers; warmed, skipped, bounded-failure, and timeout outcomes through an injected spawn.
  • tests/boundary/filesystem/setupRegistrationPrewarm.test.ts (boundary): the workflow invokes the capability exactly once after configuring clients; a failed prewarm keeps setup ready and emits a warning progress event; a host without the capability omits the summary. These hosts pin nodeVersion so readiness does not depend on the developer machine's runtime.

Verification

Run locally on Windows 11, Node 24.14.0 (below the repository pin 24.22.1, engine checks relaxed):

  • tsc --noEmit clean; oxlint 0 errors with no new warnings on modified files (the two warnings in the new module mirror the existing control-character sanitization pattern in SetupHost.ts); oxfmt --check clean; verify:module-boundaries, verify-test-discovery (2424 test files), and verify:architecture-guards pass; knip output identical to the pristine tree.
  • Focused tests: 11/11 across both new files. Full services project run shows only the 4 failures in environmentBuild.test.ts and decompileAll.test.ts that reproduce identically on the pristine tree on this machine (not caused by this change).
  • End-to-end against the built output: warm prewarm returns {"status":"warmed"} in ~1.6 s from a REA source checkout (neutral-cwd fix above); after deleting the pinned _npx entry, prewarm absorbs the 19 s cold install and returns {"status":"warmed"}, leaving nothing to install inside a client startup deadline.

Not run locally: the full check pipeline on the repository-pinned Node and the built-lane suites; CI coverage for those is expected. Bun bunx warm-up shares the command derivation but was not executed (no Bun on this machine).

Ownership

The PR author is the human owner of this change per the contribution policy.

Author readiness

Human owner: @wxj006007

  • I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
  • I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
  • I declare this PR ready for initial maintainer review.

🔄 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/7032 **Author:** [@wxj006007](https://github.com/wxj006007) **Created:** 10/24/2026 **Status:** ✅ Merged **Merged:** 10/24/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/setup-prewarm-pinned-runner` --- ### 📝 Commits (3) - [`c7b552a`](https://github.com/morluto/rea/commit/c7b552ae8239e69ce5a64f5c7324700169a733e1) fix(setup): materialize the pinned package-runner cache before the first client start - [`88dd2c1`](https://github.com/morluto/rea/commit/88dd2c111ac5ee4254f01e74f8cf77f16d0cae51) fix(setup): gate prewarm to applied registrations and supervise the runner tree - [`92a86f9`](https://github.com/morluto/rea/commit/92a86f9920a8ad8d857b1618896131616ddcfe23) fix(setup): forward terminal interrupts to the detached prewarm runner ### 📊 Changes **8 files changed** (+680 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `docs/installation.md` (+7 -0) 📝 `src/application/Setup.ts` (+30 -0) 📝 `src/application/SetupHost.ts` (+12 -1) ➕ `src/application/SetupRegistrationPrewarm.test.ts` (+181 -0) ➕ `src/application/SetupRegistrationPrewarm.ts` (+207 -0) 📝 `src/application/SetupTypes.ts` (+8 -0) 📝 `src/cli/interactiveSetup.ts` (+2 -0) ➕ `tests/boundary/filesystem/setupRegistrationPrewarm.test.ts` (+233 -0) </details> ### 📄 Description Fixes #7027 ## Problem Package runners key their package cache by the requested spec, so the `_npx` entry installed for the `rea-agents@latest` invocation that ran setup cannot serve the pinned `rea-agents@<version>` registration that setup writes. The first client start after setup installs that entry inside the client's MCP startup deadline; one client log recorded three consecutive `connection timed out after 30000ms` failures, and a controlled cold install with every tarball already in `_cacache` took 22 s on the same machine (issue has the full measurements). ## Change - `src/application/SetupRegistrationPrewarm.ts`: derives a cache-materializing variant of the registration command (same spec, terminating `--version` subcommand) and materializes it once through `execFileOutput` with a bounded timeout. Direct launcher registrations return `skipped`. The spawn runs in a neutral working directory: inside a REA source checkout the package runner resolves the local project instead of the published entry and the warm-up fails. - `SetupHost.systemSetupHost` exposes this as the optional host capability `prewarmRegistrationRunner`; `runSetupWorkflow` invokes it after client configuration and skill installation succeed, before the final doctor summary. The step is best-effort and non-fatal: `SetupResult` carries an optional `prewarm` summary, interactive output prints a warning line on failure, and hosts without the capability are unaffected. - `docs/installation.md`: documents why setup performs this step and what happens when it cannot run. ## Tests - `src/application/SetupRegistrationPrewarm.test.ts` (services): command derivation for npx/bunx/Windows-wrapped and direct launchers; warmed, skipped, bounded-failure, and timeout outcomes through an injected spawn. - `tests/boundary/filesystem/setupRegistrationPrewarm.test.ts` (boundary): the workflow invokes the capability exactly once after configuring clients; a failed prewarm keeps setup `ready` and emits a warning progress event; a host without the capability omits the summary. These hosts pin `nodeVersion` so readiness does not depend on the developer machine's runtime. ## Verification Run locally on Windows 11, Node 24.14.0 (below the repository pin 24.22.1, engine checks relaxed): - `tsc --noEmit` clean; `oxlint` 0 errors with no new warnings on modified files (the two warnings in the new module mirror the existing control-character sanitization pattern in `SetupHost.ts`); `oxfmt --check` clean; `verify:module-boundaries`, `verify-test-discovery` (2424 test files), and `verify:architecture-guards` pass; `knip` output identical to the pristine tree. - Focused tests: 11/11 across both new files. Full `services` project run shows only the 4 failures in `environmentBuild.test.ts` and `decompileAll.test.ts` that reproduce identically on the pristine tree on this machine (not caused by this change). - End-to-end against the built output: warm prewarm returns `{"status":"warmed"}` in ~1.6 s from a REA source checkout (neutral-cwd fix above); after deleting the pinned `_npx` entry, prewarm absorbs the 19 s cold install and returns `{"status":"warmed"}`, leaving nothing to install inside a client startup deadline. Not run locally: the full `check` pipeline on the repository-pinned Node and the built-lane suites; CI coverage for those is expected. Bun `bunx` warm-up shares the command derivation but was not executed (no Bun on this machine). ## Ownership The PR author is the human owner of this change per the contribution policy. ## Author readiness Human owner: @wxj006007 - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-11-03 13:38:55 +00:00
Sign in to join this conversation.
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#7588
No description provided.