[PR #6944] [MERGED] test(cli): time Kuna cleanup from producer readiness #7467

New issue

Closed

opened 2026-11-01 21:48:03 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:48:03 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/6944
Author: @gensokyo-dev
Created: 10/24/2026
Status: ✅ Merged
Merged: 10/24/2026
Merged by: @gensokyo-dev

Base: main ← Head: test/kuna-probe-clock

📝 Commits (1)

e796a13 test(cli): time Kuna cleanup from producer readiness

📊 Changes

1 file changed (+8 additions, -4 deletions)

View changed files

📝 tests/boundary/cli/kunaDoctorHeldOutput.test.ts (+8 -4)

📄 Description

Problem and outcome

The Kuna held-output regression waits for a probe marker but measures its 16 s probe/cleanup assertion from the command-start phase. CLI startup can consume that allowance: CI on the preceding maintenance PR failed at 16566 ms while the production probe had its own 10000 ms deadline.

Have the fixture producer record probeReadyAt when it creates the pipe-holding descendant, validate that timestamp with the existing marker schema, and measure probe/cleanup from that fact. This includes delays in the worker observing the marker. Keep a separate command clock beginning before invocation for missing-marker diagnostics.

All values stay the same: 10 s reported production deadline, 16 s probe/cleanup assertion, 20 s whole-command protection and the descendant's 28 s fallback. The whole command can legitimately take longer than 16 s while startup and the probe each remain bounded. Exact captured output/exit diagnostics, executable identity and empty owned-process-group assertions remain intact. Product code is unchanged. This is a direct repair of observed CI timing drift; no separate issue was opened.

Executed validation

Linux x64, Node 24.22.1 / npm 11.16.0, two CPUs:

Clean exact CI base 7f70797b9, original 384 MiB policy, controlled 7 s delay only before CLI entry — same assertion failed at 16387 ms. Isolated original runs also pass, so timing alone is load-sensitive; this is not claimed to fail deterministically on every host/run.
Updated producer clock with that startup-delay control — passed, including complete version diagnostics and confirmed process-group cleanup (15.40 s wall / 6.35 s CPU / 737.5 MiB sampled family RSS).
npm run test:focused -- tests/boundary/cli/kunaDoctorHeldOutput.test.ts tests/boundary/cli/kunaDoctorIdentity.test.ts tests/boundary/providers/kuna/kunaVersionProbeOwnership.test.ts — 10 passed, covering output-pipe holds, changed executable identity, cleanup-only ownership and cleanup retry. 16.88 s wall / 17.45 s CPU / 1415.5 MiB sampled family RSS.
After moving the diagnostic command clock before invocation: changed held-output test rechecked — 1 passed; final npm run check passed (38.73 s wall / 71.01 s CPU / 2733.6 MiB peak). git diff --check passed.

Build cache was warm and process fixtures were fresh. RSS sums descendants at 100 ms intervals; shared pages may double-count and short-lived/reparented children may be missed. Runs had elapsed limits and an 8 GiB sampled stop. These are validation costs; no suite-speedup or agent-token claim. Real Node processes and Linux ownership supervision are exercised; no real Kuna engine or macOS execution is claimed.

CI and review

CI run 40059107848 completed: all eight built test shards passed, including the changed held-output test (13.684 s). Static checks and runtime build passed. Readiness and PR-title checks passed; Codex reviewed exact head e796a130c with no findings.

The overall gate is not green: source tests report two failures in src/native/AppleDispatchMetadata.failure.test.ts (expected AnalysisInputError, received AnalysisArtifactChangedError), and Portable tests / CI required propagate that result. Both exact failure names and assertions reproduce on a clean detached worktree at this PR's actual base 39aca9223: 2 failed / 3 passed, 9.48 s wall / 10.64 s CPU / 783.3 MiB sampled family RSS. These are independent baseline failures; this test-only PR does not modify that producer or its consumers. They are left outside this change under the owner's instruction to address only PR-caused CI regressions.

Post-merge validation

Clean detached worktree at merged main f9fabdfcb with a fresh locked dependency installation: all five relevant test files / 29 tests passed, including both changes together. The focused command built required artifacts with 0/3 cached tasks; 49.34 s elapsed / 70.15 s CPU / 1952.3 MiB sampled process-family RSS. Worker concurrency and host CPU affinity remained bounded at two CPUs. The merged config, policy test and Kuna regression match the reviewed changes; later unrelated documentation edits remain intact. Final npm run check passed (26.48 s wall / 48.70 s CPU / 2622.8 MiB sampled family RSS; 2/6 static tasks cached). The real /usr/bin/tshark and /usr/bin/capinfos 4.0.17 verifier passed named schemas and CLI/MCP Evidence parity on an offline synthetic one-packet PCAP: 1 packet, 2 addresses, complete coverage; 13.15 s wall / 14.93 s CPU / 1240.8 MiB sampled family RSS. No live capture or real Kuna engine is claimed. Post-merge worktree and git diff --check are clean.

Author readiness

Human owner: @gensokyo-dev

The owner explicitly delegated readiness declarations and agent-managed review. Code inspection and command execution above were performed by Codex; no separate human inspection is claimed.

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/6944 **Author:** [@gensokyo-dev](https://github.com/gensokyo-dev) **Created:** 10/24/2026 **Status:** ✅ Merged **Merged:** 10/24/2026 **Merged by:** [@gensokyo-dev](https://github.com/gensokyo-dev) **Base:** `main` ← **Head:** `test/kuna-probe-clock` --- ### 📝 Commits (1) - [`e796a13`](https://github.com/morluto/rea/commit/e796a130c2895a38888371df61b4e293b6936900) test(cli): time Kuna cleanup from producer readiness ### 📊 Changes **1 file changed** (+8 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `tests/boundary/cli/kunaDoctorHeldOutput.test.ts` (+8 -4) </details> ### 📄 Description ## Problem and outcome The Kuna held-output regression waits for a probe marker but measures its 16 s probe/cleanup assertion from the command-start phase. CLI startup can consume that allowance: [CI on the preceding maintenance PR](https://github.com/morluto/rea/actions/runs/40056596476/job/120761057519) failed at 16566 ms while the production probe had its own 10000 ms deadline. Have the fixture producer record `probeReadyAt` when it creates the pipe-holding descendant, validate that timestamp with the existing marker schema, and measure probe/cleanup from that fact. This includes delays in the worker observing the marker. Keep a separate command clock beginning before invocation for missing-marker diagnostics. All values stay the same: 10 s reported production deadline, 16 s probe/cleanup assertion, 20 s whole-command protection and the descendant's 28 s fallback. The whole command can legitimately take longer than 16 s while startup and the probe each remain bounded. Exact captured output/exit diagnostics, executable identity and empty owned-process-group assertions remain intact. Product code is unchanged. This is a direct repair of observed CI timing drift; no separate issue was opened. ## Executed validation Linux x64, Node 24.22.1 / npm 11.16.0, two CPUs: - Clean exact CI base `7f70797b9`, original 384 MiB policy, controlled 7 s delay **only before CLI entry** — same assertion failed at 16387 ms. Isolated original runs also pass, so timing alone is load-sensitive; this is not claimed to fail deterministically on every host/run. - Updated producer clock with that startup-delay control — passed, including complete version diagnostics and confirmed process-group cleanup (15.40 s wall / 6.35 s CPU / 737.5 MiB sampled family RSS). - `npm run test:focused -- tests/boundary/cli/kunaDoctorHeldOutput.test.ts tests/boundary/cli/kunaDoctorIdentity.test.ts tests/boundary/providers/kuna/kunaVersionProbeOwnership.test.ts` — **10 passed**, covering output-pipe holds, changed executable identity, cleanup-only ownership and cleanup retry. 16.88 s wall / 17.45 s CPU / 1415.5 MiB sampled family RSS. - After moving the diagnostic command clock before invocation: changed held-output test rechecked — **1 passed**; final `npm run check` passed (38.73 s wall / 71.01 s CPU / 2733.6 MiB peak). `git diff --check` passed. Build cache was warm and process fixtures were fresh. RSS sums descendants at 100 ms intervals; shared pages may double-count and short-lived/reparented children may be missed. Runs had elapsed limits and an 8 GiB sampled stop. These are validation costs; no suite-speedup or agent-token claim. Real Node processes and Linux ownership supervision are exercised; no real Kuna engine or macOS execution is claimed. ## CI and review [CI run 40059107848](https://github.com/morluto/rea/actions/runs/40059107848) completed: **all eight built test shards passed**, including the changed held-output test (13.684 s). Static checks and runtime build passed. Readiness and PR-title checks passed; Codex reviewed exact head `e796a130c` with no findings. The overall gate is **not green**: source tests report two failures in `src/native/AppleDispatchMetadata.failure.test.ts` (expected `AnalysisInputError`, received `AnalysisArtifactChangedError`), and Portable tests / CI required propagate that result. Both exact failure names and assertions reproduce on a clean detached worktree at this PR's actual base `39aca9223`: 2 failed / 3 passed, 9.48 s wall / 10.64 s CPU / 783.3 MiB sampled family RSS. These are independent baseline failures; this test-only PR does not modify that producer or its consumers. They are left outside this change under the owner's instruction to address only PR-caused CI regressions. ## Post-merge validation Clean detached worktree at merged main `f9fabdfcb` with a fresh locked dependency installation: all five relevant test files / **29 tests passed**, including both changes together. The focused command built required artifacts with 0/3 cached tasks; 49.34 s elapsed / 70.15 s CPU / 1952.3 MiB sampled process-family RSS. Worker concurrency and host CPU affinity remained bounded at two CPUs. The merged config, policy test and Kuna regression match the reviewed changes; later unrelated documentation edits remain intact. Final `npm run check` passed (26.48 s wall / 48.70 s CPU / 2622.8 MiB sampled family RSS; 2/6 static tasks cached). The real `/usr/bin/tshark` and `/usr/bin/capinfos` 4.0.17 verifier passed named schemas and CLI/MCP Evidence parity on an offline synthetic one-packet PCAP: 1 packet, 2 addresses, complete coverage; 13.15 s wall / 14.93 s CPU / 1240.8 MiB sampled family RSS. No live capture or real Kuna engine is claimed. Post-merge worktree and `git diff --check` are clean. ## Author readiness Human owner: @gensokyo-dev The owner explicitly delegated readiness declarations and agent-managed review. Code inspection and command execution above were performed by Codex; no separate human inspection is claimed. - [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-01 21:48:03 +00:00