[PR #232] [MERGED] fix(process): stabilize and speed up the test suite #1884

New issue

Closed

opened 2026-10-16 21:12:09 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:12:09 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/232
Author: @N0zoM1z0
Created: 7/14/2026
Status: ✅ Merged
Merged: 7/14/2026
Merged by: @morluto

Base: main ← Head: codex/test-suite-speed

📝 Commits (4)

2223da1 test: reduce test suite runtime
40c6f60 fix(process): restrict cleanup to captured group leaders
f46fc7f test: serialize subprocess-heavy integrations
8681d81 Merge branch 'main' into codex/test-suite-speed

📊 Changes

16 files changed (+465 additions, -75 deletions)

View changed files

📝 package.json (+1 -0)
➕ scripts/build-cache.mjs (+103 -0)
📝 scripts/generate-package-metadata.mjs (+17 -1)
➕ scripts/record-build-cache.mjs (+7 -0)
📝 src/application/ProcessCaptureLifecycle.ts (+2 -6)
📝 src/application/ProcessHarness.ts (+11 -10)
📝 src/application/ProcessOwnership.ts (+17 -0)
📝 tests/artifactProvider.test.ts (+13 -11)
📝 tests/bridgeRegex.test.ts (+189 -11)
📝 tests/contractSnapshot.test.ts (+23 -16)
📝 tests/enhancedTools.test.ts (+4 -5)
📝 tests/fixtures/bridgeRegexProbe.py (+8 -2)
📝 tests/processOwnership.test.ts (+13 -0)
📝 tests/providerArchitecture.test.ts (+20 -12)
📝 tsconfig.build.json (+2 -0)
📝 vitest.config.ts (+35 -1)

📄 Description

Summary

Use both workers on two-core runners for safe test files while running subprocess- and PTY-heavy integrations sequentially.
Reuse one Python bridge-regex probe process instead of starting Python and loading the bridge for every assertion, while retaining its packaged-verifier one-shot interface.
Run independent MCP, artifact, schema, and filesystem checks concurrently while preserving assertions and result ordering.
Cache repeated Zod-to-JSON-Schema conversions.
Enable safe incremental TypeScript builds by avoiding unchanged metadata writes and validating cached outputs with SHA-256 digests before reuse.
Fix process cleanup so only the PTY root and process groups whose leaders were observed inside the captured tree are settled and signaled.

Why

On two-core environments, Vitest's default worker calculation leaves the suite with one worker. Several tests also repeated expensive subprocess, Python-import, schema-conversion, and build work.

The existing PTY failures had a separate root cause: a captured process can transiently inherit an unrelated process group. Cleanup treated every sampled group ID as captured, then correctly failed closed when the unrelated group did not carry the run token. Selecting only observed captured group leaders preserves the ownership boundary without attempting to signal unrelated processes.

Impact

Process cleanup remains fail-closed and no longer mistakes an inherited external group for a captured group.
Timeout-sensitive CLI, browser, runtime, and PTY files do not compete with each other.
No tests were removed; the PR base discovers all 101 test files exactly once.
Coverage includes, thresholds, reporters, retries, and assertions are unchanged.
Incremental state is stored under node_modules/.cache; missing or modified dist output invalidates the cache and triggers a full rebuild through npm run build.

Performance

Representative measurements on Node.js 22.19.0:

Five-file modified-test subset, one worker, coverage disabled: 26.98s → 16.33s Vitest duration (39% faster), with all 48 tests passing in both runs.
Repeated TypeScript build user CPU time: 17.15s → 3.70s (78% lower).
Removing dist and tampering with an emitted file both invalidated the build cache; the subsequent full rebuild restored byte-identical output.

Verification

npm run build
npm run typecheck -- --pretty false
npm run lint (passes with existing repository warnings)
npm run format:check
Process-focused suite: 4 consecutive retry-free runs, 35/35 tests each
Focused modified-test suite: 7 files, 55 tests passed
vitest list --filesOnly: 101 unique files, no duplicates
Missing-output and tampered-output build-cache recovery
Persistent and one-shot bridge-regex probe modes

A local full run was also used to uncover and remove file-level contention. During the final rerun the shared two-core host was under load averages above 11 from several unrelated worktrees, causing timeout-sensitive tests to exceed their existing budgets; those files are now isolated in the serial integration project. GitHub's dedicated coverage/timing job is the authoritative full-suite verification.

npm run verify:package was attempted locally; it built successfully but the environment stopped the verifier at its configured unsupported Hopper build before package verification completed.

Real Hopper and real browser verification were not performed.

_{🔄 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/232 **Author:** [@N0zoM1z0](https://github.com/N0zoM1z0) **Created:** 7/14/2026 **Status:** ✅ Merged **Merged:** 7/14/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `codex/test-suite-speed` --- ### 📝 Commits (4) - [`2223da1`](https://github.com/morluto/rea/commit/2223da19166a3ec485d98a0d005113a9d0358f37) test: reduce test suite runtime - [`40c6f60`](https://github.com/morluto/rea/commit/40c6f60ac9a4b86f4cbe28a72e7692e1acf761b1) fix(process): restrict cleanup to captured group leaders - [`f46fc7f`](https://github.com/morluto/rea/commit/f46fc7f1f3a265123c69d007c64c928a8974d98f) test: serialize subprocess-heavy integrations - [`8681d81`](https://github.com/morluto/rea/commit/8681d817f9d06495ba44f5f5dd66d4442cd96eeb) Merge branch 'main' into codex/test-suite-speed ### 📊 Changes **16 files changed** (+465 additions, -75 deletions) <details> <summary>View changed files</summary> 📝 `package.json` (+1 -0) ➕ `scripts/build-cache.mjs` (+103 -0) 📝 `scripts/generate-package-metadata.mjs` (+17 -1) ➕ `scripts/record-build-cache.mjs` (+7 -0) 📝 `src/application/ProcessCaptureLifecycle.ts` (+2 -6) 📝 `src/application/ProcessHarness.ts` (+11 -10) 📝 `src/application/ProcessOwnership.ts` (+17 -0) 📝 `tests/artifactProvider.test.ts` (+13 -11) 📝 `tests/bridgeRegex.test.ts` (+189 -11) 📝 `tests/contractSnapshot.test.ts` (+23 -16) 📝 `tests/enhancedTools.test.ts` (+4 -5) 📝 `tests/fixtures/bridgeRegexProbe.py` (+8 -2) 📝 `tests/processOwnership.test.ts` (+13 -0) 📝 `tests/providerArchitecture.test.ts` (+20 -12) 📝 `tsconfig.build.json` (+2 -0) 📝 `vitest.config.ts` (+35 -1) </details> ### 📄 Description ## Summary - Use both workers on two-core runners for safe test files while running subprocess- and PTY-heavy integrations sequentially. - Reuse one Python bridge-regex probe process instead of starting Python and loading the bridge for every assertion, while retaining its packaged-verifier one-shot interface. - Run independent MCP, artifact, schema, and filesystem checks concurrently while preserving assertions and result ordering. - Cache repeated Zod-to-JSON-Schema conversions. - Enable safe incremental TypeScript builds by avoiding unchanged metadata writes and validating cached outputs with SHA-256 digests before reuse. - Fix process cleanup so only the PTY root and process groups whose leaders were observed inside the captured tree are settled and signaled. ## Why On two-core environments, Vitest's default worker calculation leaves the suite with one worker. Several tests also repeated expensive subprocess, Python-import, schema-conversion, and build work. The existing PTY failures had a separate root cause: a captured process can transiently inherit an unrelated process group. Cleanup treated every sampled group ID as captured, then correctly failed closed when the unrelated group did not carry the run token. Selecting only observed captured group leaders preserves the ownership boundary without attempting to signal unrelated processes. ## Impact - Process cleanup remains fail-closed and no longer mistakes an inherited external group for a captured group. - Timeout-sensitive CLI, browser, runtime, and PTY files do not compete with each other. - No tests were removed; the PR base discovers all 101 test files exactly once. - Coverage includes, thresholds, reporters, retries, and assertions are unchanged. - Incremental state is stored under `node_modules/.cache`; missing or modified `dist` output invalidates the cache and triggers a full rebuild through `npm run build`. ## Performance Representative measurements on Node.js 22.19.0: - Five-file modified-test subset, one worker, coverage disabled: **26.98s → 16.33s** Vitest duration (**39% faster**), with all 48 tests passing in both runs. - Repeated TypeScript build user CPU time: **17.15s → 3.70s** (**78% lower**). - Removing `dist` and tampering with an emitted file both invalidated the build cache; the subsequent full rebuild restored byte-identical output. ## Verification - `npm run build` - `npm run typecheck -- --pretty false` - `npm run lint` (passes with existing repository warnings) - `npm run format:check` - Process-focused suite: 4 consecutive retry-free runs, 35/35 tests each - Focused modified-test suite: 7 files, 55 tests passed - `vitest list --filesOnly`: 101 unique files, no duplicates - Missing-output and tampered-output build-cache recovery - Persistent and one-shot bridge-regex probe modes A local full run was also used to uncover and remove file-level contention. During the final rerun the shared two-core host was under load averages above 11 from several unrelated worktrees, causing timeout-sensitive tests to exceed their existing budgets; those files are now isolated in the serial integration project. GitHub's dedicated coverage/timing job is the authoritative full-suite verification. `npm run verify:package` was attempted locally; it built successfully but the environment stopped the verifier at its configured unsupported Hopper build before package verification completed. Real Hopper and real browser verification were not performed. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-16 21:12:09 +00:00