morluto/rea

Fork 0

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

[GH-ISSUE #5050] [Bug] Wall-clock deadline regression test cancels healthy captures on the macOS lane #3096

New issue

Closed

opened 2026-10-31 00:36:35 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:36:35 +00:00

Owner

Originally created by @viniciusdsandrade on GitHub (Oct 18, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5050

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Process capture or runtime observation

Observed behavior

tests/boundary/process/processCaptureLifecycle.test.ts > keeps the process deadline bounded when the wall clock moves backward failed twice in the Real Apple artifact CLI/MCP E2E job (macos-15) with AssertionError: expected false to be true:

CI run	Event	Commit	Test duration
39089233220	pull_request	`1aaa5044d`	1522 ms
39105114070	schedule on main	`8f7d12e30`	1820 ms

Source-derived: the test arms a 1500 ms abort guard (processCaptureLifecycle.test.ts:185). An abort makes the capture reject as cancelled (src/process/capture/ProcessHarness.ts:754), so result.ok is false and the first assertion (:197) fails before throw result.error (:198) can report the cause. Both durations sit just above the guard.

Reproduction

NOT_ENOUGH_INFO: I did not reproduce this locally or on demand. The evidence is read from CI job logs. Healthy timings of the same test in the 40 most recent successful CI runs (2026-10-18 11:36 to 16:30 UTC):

Lane	Samples	Min	Median	Max
`macos-15` (Real Apple artifact CLI/MCP E2E)	15	579 ms	883 ms	1304 ms
ubuntu test shards	38	439 ms	535 ms	841 ms

Expected behavior

The test should fail only when the capture deadline follows the rewound wall clock, the behavior fixed in 9049dbaf0. A healthy capture on a slow hosted macOS runner should pass, and an unexpected capture failure should print its own error instead of a bare boolean assertion.

Impact and scope

Intermittent failures of the macOS lane. Two failures are visible among the 200 most recent failed CI runs (2026-10-17 13:21 to 2026-10-18 15:41 UTC); both are on macos-15. No product behavior is affected. How often the guard fires on other hosts or on developer machines is unknown.

REA version

23f984b1a (main). The test body is unchanged since 9049dbaf0.

Runtime and platform

GitHub-hosted macos-15 runner, Node.js from .nvmrc.

Target and artifact context

Not applicable. The target is the test's Node fixture process in hang mode.

Interface

Other

Earliest failure stage

Cleanup, cancellation, or lifecycle

Relevant output or evidence

Command actually run: gh run view 39105114070 --log-failed, and the same for 39089233220, to read the CI job logs.

Relevant result: × keeps the process deadline bounded when the wall clock moves backward 1820ms, followed by AssertionError: expected false to be true // Object.is equality in the macOS lane.

Source: tests/boundary/process/processCaptureLifecycle.test.ts:184-198 at 23f984b1a.

Missing evidence: the current assertion order never prints the cancellation error, so cancellation by the guard is inferred from the timings and not observed directly.

Typed outcome or recovery expected

On an unexpected capture failure, the log should show the ProcessCaptureError instead of expected false to be true.

Analysis or suspected cause

Timing-derived, not observed directly: the 1500 ms guard is about 15 percent above the slowest healthy macOS sample (1304 ms), so a slow runner start cancels a healthy capture. The guard exists only to stop the test early if the deadline followed the rewound clock. Any value well below the 10000 ms test timeout does that, so the guard can be raised without weakening what the test proves.

Proposed check: raise the guard to 5000 ms and report result.error before the success assertion. I can send this as a small test-only change.

Originally created by @viniciusdsandrade on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5050 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Process capture or runtime observation ### Observed behavior `tests/boundary/process/processCaptureLifecycle.test.ts` > `keeps the process deadline bounded when the wall clock moves backward` failed twice in the `Real Apple artifact CLI/MCP E2E` job (`macos-15`) with `AssertionError: expected false to be true`: | CI run | Event | Commit | Test duration | | --- | --- | --- | --- | | 39089233220 | pull_request | 1aaa5044d | 1522 ms | | 39105114070 | schedule on main | 8f7d12e30 | 1820 ms | Source-derived: the test arms a 1500 ms abort guard (`processCaptureLifecycle.test.ts:185`). An abort makes the capture reject as cancelled (`src/process/capture/ProcessHarness.ts:754`), so `result.ok` is false and the first assertion (`:197`) fails before `throw result.error` (`:198`) can report the cause. Both durations sit just above the guard. ### Reproduction NOT_ENOUGH_INFO: I did not reproduce this locally or on demand. The evidence is read from CI job logs. Healthy timings of the same test in the 40 most recent successful CI runs (2026-10-18 11:36 to 16:30 UTC): | Lane | Samples | Min | Median | Max | | --- | --- | --- | --- | --- | | `macos-15` (Real Apple artifact CLI/MCP E2E) | 15 | 579 ms | 883 ms | 1304 ms | | ubuntu test shards | 38 | 439 ms | 535 ms | 841 ms | ### Expected behavior The test should fail only when the capture deadline follows the rewound wall clock, the behavior fixed in 9049dbaf0. A healthy capture on a slow hosted macOS runner should pass, and an unexpected capture failure should print its own error instead of a bare boolean assertion. ### Impact and scope Intermittent failures of the macOS lane. Two failures are visible among the 200 most recent failed CI runs (2026-10-17 13:21 to 2026-10-18 15:41 UTC); both are on `macos-15`. No product behavior is affected. How often the guard fires on other hosts or on developer machines is unknown. ### REA version `23f984b1a` (main). The test body is unchanged since 9049dbaf0. ### Runtime and platform GitHub-hosted `macos-15` runner, Node.js from `.nvmrc`. ### Target and artifact context Not applicable. The target is the test's Node fixture process in `hang` mode. ### Interface Other ### Earliest failure stage Cleanup, cancellation, or lifecycle ### Relevant output or evidence Command actually run: `gh run view 39105114070 --log-failed`, and the same for 39089233220, to read the CI job logs. Relevant result: `× keeps the process deadline bounded when the wall clock moves backward 1820ms`, followed by `AssertionError: expected false to be true // Object.is equality` in the macOS lane. Source: `tests/boundary/process/processCaptureLifecycle.test.ts:184-198` at `23f984b1a`. Missing evidence: the current assertion order never prints the cancellation error, so cancellation by the guard is inferred from the timings and not observed directly. ### Typed outcome or recovery expected On an unexpected capture failure, the log should show the `ProcessCaptureError` instead of `expected false to be true`. ### Analysis or suspected cause Timing-derived, not observed directly: the 1500 ms guard is about 15 percent above the slowest healthy macOS sample (1304 ms), so a slow runner start cancels a healthy capture. The guard exists only to stop the test early if the deadline followed the rewound clock. Any value well below the 10000 ms test timeout does that, so the guard can be raised without weakening what the test proves. Proposed check: raise the guard to 5000 ms and report `result.error` before the success assertion. I can send this as a small test-only change.

bsakaguchi closed this issue

2026-10-31 00:36:35 +00:00

bsakaguchi commented

2026-10-31 00:36:36 +00:00

Author

Owner

@viniciusdsandrade commented on GitHub (Oct 21, 2026):

Resolved by #5224 (b999e7247): the fallback abort now arms only after the capture reaches the running phase and is cleared on settling or cleanup, so startup latency no longer counts against it.

@viniciusdsandrade commented on GitHub (Oct 21, 2026): Resolved by #5224 (b999e7247): the fallback abort now arms only after the capture reaches the running phase and is cleared on settling or cleanup, so startup latency no longer counts against it.

bsakaguchi referenced this issue

2026-10-31 01:08:01 +00:00

[PR #3103] [CLOSED] fix(ghidra): parse and reconcile MIPS GNU ABI attributes #5618

bsakaguchi referenced this issue

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

[PR #4532] fix(ghidra): admit recordless legacy MIPS32 carves missing section tables #6291