test: stabilize load-sensitive test families that break gates under parallel load#100420
Conversation
openclaw-barnacle
Bot
added
channel: matrix
|
Codex review: needs real behavior proof before merge. Reviewed July 5, 2026, 3:37 PM ET / 19:37 UTC. Summary PR surface: Source +20, Tests +37. Total +57 across 6 files. Reproducibility: no. high-confidence independent reproduction was established in this read-only review. The PR body reports repeated parallel-load gate failures and focused stress loops, and source inspection confirms the touched tests exercise real pending-work, process-signal, and probe-timeout paths. Review metrics: none identified. Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Keep this as the active test-stability PR and merge only after maintainer review and exact-head CI remain green; no cleanup close or replacement PR is supported. Do we have a high-confidence way to reproduce the issue? No high-confidence independent reproduction was established in this read-only review. The PR body reports repeated parallel-load gate failures and focused stress loops, and source inspection confirms the touched tests exercise real pending-work, process-signal, and probe-timeout paths. Is this the best way to solve the issue? Yes, this appears to be the best maintainable shape for the reported gate instability. The PR tightens test synchronization at existing owner boundaries instead of changing production runtime behavior or adding broad timeout inflation. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against a320f775f0f3. Label changesLabel justifications:
Evidence reviewedPR surface: Source +20, Tests +37. Total +57 across 6 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (1 earlier review cycle)
|
clawsweeper
Bot
added
rating: 🐚 platinum hermit
272c166 to
5f8300a
Compare
5f8300a to
294c4d3
Compare
|
Merged via squash.
|
…arallel load (openclaw#100420) * test: stabilize process-heavy fixtures under load * test: stabilize channel mocks under load
1 participant
What Problem This Solves
Six test families fail under parallel load while passing in serial isolation — they have repeatedly broken local landing gates and CI reruns (observed across five consecutive gate runs on a busy machine): the WhatsApp monitor-inbox media test, four tooling subprocess/signal suites (run-vitest wrapper cleanup, kitchen-sink fixture-server startup, write-cli-startup-metadata descendants, upgrade-survivor probe timing), and the Matrix crypto-bootstrap mock.
Why This Change Was Made
Each family's load sensitivity had a specific mechanism, fixed at the source rather than by inflating limits: subprocess fixtures now use a shared named
LOAD_SENSITIVE_PROCESS_TIMEOUT_MSwhere the timeout only guards against genuinely broken fixtures (readiness/close signals do the real synchronization); the upgrade-survivor probe tests got injectable time so total-timeout ASSERTIONS stay meaningful instead of racing the wall clock; a child fixture pins scheduling with a setTimeout shim; the WhatsApp media-path test-support and Matrix mocks were made complete for everything production touches (per the repo's vi.mock completeness rule). No production code changed; no baselines/snapshots touched.User Impact
None at runtime. Contributors and landing pipelines stop losing runs to these six families; test-suite results become trustworthy under machine load.
Evidence
Promise.withResolversreplaced with ES2023-compatible resolver); final run clean.