morluto/rea

Fork 0

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

[GH-ISSUE #5889] [Bug] Sparse process-capture progress CI check reports more than two frames #3570

New issue

Closed

opened 2026-10-31 00:41:58 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-31 00:41:58 +00:00

Owner

Originally created by @gensokyo-dev on GitHub (Oct 21, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5889

Before submitting / area

Searched existing processCaptureProgress reports; #3052/#3169 concern different terminal-progress fields/cleanup behavior.
No credentials, private target data or installation paths included.

Area: Process capture / test correctness.

Observed behavior

In CI job 119168728306, tests/boundary/process/processCaptureProgress.test.ts failed its sparse-child assertion at line 276:

expect(running.every(({ details }) => details.frames <= 2)).toBe(true);

Actual boolean: false. Earlier assertions had already accepted exit code 0, parsed successful capture Evidence, both sparse progress/data channel checks and monotonic progress. The exact largest frame count is NOT_ENOUGH_INFO: the assertion logged only the boolean, not the updates.

Reproduction actually run

The CI test runs a Node child that writes SPARSE_CHILD_STARTED, waits 1600ms, then writes SPARSE_CHILD_DONE; it records CLI Evidence on stdout and progress on stderr. Scenario execution/idle budgets are 10000ms. The job finished with one failed test, 1514 passed and 23 skipped.

As a pre-feature control, ran npm run test:focused -- tests/boundary/process/processCaptureProgress.test.ts on baseline f801b2fbfd with pinned Node 24.18.0/Linux x64: 7/7 passed, 73.48s Vitest duration. That did not reproduce the exact failure; it must not be described as a baseline runtime reproduction. A diagnostic rerun on the unchanged PR head passed (job 119173133543, completed 2026-10-21T10:41:35Z). This establishes a non-deterministic outcome for that PR head, not a causal fix or reliable failure-rate estimate.

Expected behavior / impact

Successful capture progress should preserve the actual frame/data semantics. Any two-frame upper bound needs support from the producer contract rather than an assumed mapping from two writes to at most two recorded frames. Whether the observed count is a valid extra frame, a transport/chunk-boundary effect or a product bug is unknown. Do not drop frames, raise limits or relax the test solely to obtain green CI.

Observed impact: one failed shard and fail-fast cancellation of sibling shards. Broader frequency, platforms and data-integrity impact are NOT_ENOUGH_INFO.

Version / interface / earliest observed stage

CI PR head: ef70dbafcb; PR #5863.
Baseline control: f801b2fbfd; Linux x64/Node 24.18.0.
Interface: successful public CLI process capture and stderr progress, not a provider error response.
Earliest observed failure: progress-test frame-count assertion; causal stage unknown.

Analysis / proposed checks

Source comparison: #5863 changes no src/process/ code or this test. Its error-history projection is not the successful result-delivery path exercised here. This supports investigating separately, not claiming that a causal baseline defect has been proven.

Hypothesis only: the fixed upper bound may couple write count to capture chunk/frame count. Proposed checks (not executed): retain actual updates and frame kinds/content on failure, compare with the documented frame contract, and reproduce under controlled stream fragmentation/timing before selecting a fix. Keep stdout/Evidence isolation, bounded progress and cleanup assertions intact.

Originally created by @gensokyo-dev on GitHub (Oct 21, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5889 ### Before submitting / area - [x] Searched existing `processCaptureProgress` reports; #3052/#3169 concern different terminal-progress fields/cleanup behavior. - [x] No credentials, private target data or installation paths included. Area: Process capture / test correctness. ### Observed behavior In [CI job 119168728306](https://github.com/morluto/rea/actions/runs/39583737021/job/119168728306), `tests/boundary/process/processCaptureProgress.test.ts` failed its sparse-child assertion at line 276: ```ts expect(running.every(({ details }) => details.frames <= 2)).toBe(true); ``` Actual boolean: false. Earlier assertions had already accepted exit code 0, parsed successful capture Evidence, both sparse progress/data channel checks and monotonic progress. The exact largest frame count is **NOT_ENOUGH_INFO**: the assertion logged only the boolean, not the updates. ### Reproduction actually run The CI test runs a Node child that writes `SPARSE_CHILD_STARTED`, waits 1600ms, then writes `SPARSE_CHILD_DONE`; it records CLI Evidence on stdout and progress on stderr. Scenario execution/idle budgets are 10000ms. The job finished with one failed test, 1514 passed and 23 skipped. As a pre-feature control, ran `npm run test:focused -- tests/boundary/process/processCaptureProgress.test.ts` on baseline **f801b2fbfd28f4e3713adefddc7bd73db44c284c** with pinned Node 24.18.0/Linux x64: **7/7 passed**, 73.48s Vitest duration. That did **not** reproduce the exact failure; it must not be described as a baseline runtime reproduction. A diagnostic rerun on the unchanged PR head **passed** ([job 119173133543](https://github.com/morluto/rea/actions/runs/39583737021/job/119173133543), completed 2026-10-21T10:41:35Z). This establishes a non-deterministic outcome for that PR head, not a causal fix or reliable failure-rate estimate. ### Expected behavior / impact Successful capture progress should preserve the actual frame/data semantics. Any two-frame upper bound needs support from the producer contract rather than an assumed mapping from two writes to at most two recorded frames. Whether the observed count is a valid extra frame, a transport/chunk-boundary effect or a product bug is unknown. Do not drop frames, raise limits or relax the test solely to obtain green CI. Observed impact: one failed shard and fail-fast cancellation of sibling shards. Broader frequency, platforms and data-integrity impact are **NOT_ENOUGH_INFO**. ### Version / interface / earliest observed stage - CI PR head: ef70dbafcb6de1c8fea5c54e6c99e64b7b6226b9; PR #5863. - Baseline control: f801b2fbfd28f4e3713adefddc7bd73db44c284c; Linux x64/Node 24.18.0. - Interface: successful public CLI process capture and stderr progress, not a provider error response. - Earliest observed failure: progress-test frame-count assertion; causal stage unknown. ### Analysis / proposed checks Source comparison: #5863 changes no `src/process/` code or this test. Its error-history projection is not the successful result-delivery path exercised here. This supports investigating separately, not claiming that a causal baseline defect has been proven. Hypothesis only: the fixed upper bound may couple write count to capture chunk/frame count. Proposed checks (not executed): retain actual updates and frame kinds/content on failure, compare with the documented frame contract, and reproduce under controlled stream fragmentation/timing before selecting a fix. Keep stdout/Evidence isolation, bounded progress and cleanup assertions intact.

bsakaguchi

2026-10-31 00:41:58 +00:00

closed this issue
added the
bug

triage
labels

bsakaguchi commented

2026-10-31 00:41:59 +00:00

Author

Owner

@CassieFox23 commented on GitHub (Oct 23, 2026):

I'd like to take this one, with a small test-only change. If the frame check fails, it will print the progress details. Then the next failure shows the real frame counts. This only helps diagnose the flake. It does not fix it.

Thanks, gensokyo-dev, for the careful report.

🤖 Written with Claude Code (Sonnet 5.5, verified by Opus 5.5), posted with my OK 🦊

@CassieFox23 commented on GitHub (Oct 23, 2026): I'd like to take this one, with a small test-only change. If the frame check fails, it will print the progress details. Then the next failure shows the real frame counts. This only helps diagnose the flake. It does not fix it. Thanks, gensokyo-dev, for the careful report. 🤖 Written with Claude Code (Sonnet 5.5, verified by Opus 5.5), posted with my OK 🦊

bsakaguchi commented

2026-10-31 00:41:59 +00:00

Author

Owner

@morluto commented on GitHub (Oct 23, 2026):

Fixed the test-contract defect in github.com/morluto/rea@2886cc1efe. Terminal frames represent PTY transport chunks, so two child writes do not establish a two-frame maximum. Sparse progress now agrees with final retained Evidence, requires both messages and monotonic frame counts, and preserves rate, timing, stdout/stderr isolation and exact cleanup counts.

Validation: a controlled four-chunk case preserves the same two messages; all four retention tests and the selected public sparse CLI case passed. The historical CI payload and its extra-frame cause were not reproduced; no capture-frame production behavior was changed.

@morluto commented on GitHub (Oct 23, 2026): Fixed the test-contract defect in https://github.com/morluto/rea/commit/2886cc1efe3ac14d47eb2cdc2ffc9330449ad619. Terminal frames represent PTY transport chunks, so two child writes do not establish a two-frame maximum. Sparse progress now agrees with final retained Evidence, requires both messages and monotonic frame counts, and preserves rate, timing, stdout/stderr isolation and exact cleanup counts. Validation: a controlled four-chunk case preserves the same two messages; all four retention tests and the selected public sparse CLI case passed. The historical CI payload and its extra-frame cause were not reproduced; no capture-frame production behavior was changed.

bsakaguchi referenced this issue

2026-11-01 21:10:57 +00:00

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471

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

No description provided.

Rows
Columns