You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Messages ingress alternate-main success-control times out in changed-mode suite #7418
The success-control case for pool-to-native-main cancellation through messages ingress timed out at the default 5-second limit in the final-head changed-mode run for #7414. This is an existing unchanged regression file. A focused follow-up is being recorded separately; no timeout has been raised and no assertion has been removed in #7414.
Reproduction
Run OCX_TEST_RUNNER_BUN=<Bun 1.4.3> bun run test:changed at e2ab0d7. It selected 1,565 files / 35,300 cases and completed in 415.6 seconds with 35,252 pass / 43 skip / 5 fail. Four failures are tracked in #7417; the fifth is this case.
tests/responses/responses-alternate-main-cancellation.test.ts: pool to native main cancellation through messages ingress > success-control timed out after 5017ms (limit 5000ms).
Screenshots and supporting files
#7414
All 565 focused account-collision/auth/routing tests passed separately. The timeout is not described as a proven baseline bug; load sensitivity remains under investigation.
Checks
I searched existing issues and documentation.
I removed secrets, tokens, account details, request credentials, and personal data.
Focused follow-up at the same final head: bun test tests/responses/responses-alternate-main-cancellation.test.ts with Bun 1.4.3 passed 6/6 in 1.50s; the timed-out success-control took 311ms. No code, timeout or test assertion was changed. This supports a suite/load-sensitive failure, not a proven deterministic product regression.
Checked against trusted dev 12025981e5a304cdb6b1b54f525ba8554f623977. The recorded 6/6 focused follow-up (success-control 311 ms) supports a load/order-sensitive failure and does not erase the 5-second changed-mode failure. Keep the original and focused receipts distinct. The next useful regression is deterministic cancellation/producer settlement under the existing ownership harness, with one bounded workload; do not raise the global timeout or weaken the success-control. No new runtime fix is established by the present evidence.
Fixed on dev by #7468 (944647100c), which shipped in 2.91.0: the messages-ingress cancellation cases no longer dial a real wss://chatgpt.com WebSocket before the mocked fetch, which is what made the success-control case time out. Closing manually because GitHub only auto-closes from main; reopen if it recurs on current dev.
Activity
github-actions commentedon Oct 19, 2026
Automated translation bookkeeping — detected language: English.
Ingwannu commentedon Oct 20, 2026
Checked against trusted dev
12025981e5a304cdb6b1b54f525ba8554f623977. The recorded 6/6 focused follow-up (success-control 311 ms) supports a load/order-sensitive failure and does not erase the 5-second changed-mode failure. Keep the original and focused receipts distinct. The next useful regression is deterministic cancellation/producer settlement under the existing ownership harness, with one bounded workload; do not raise the global timeout or weaken the success-control. No new runtime fix is established by the present evidence.test: make update recovery, messages cancellation, and CLI parity har…
lidge-jun commentedon Oct 22, 2026
Fixed on
devby #7468 (944647100c), which shipped in 2.91.0: the messages-ingress cancellation cases no longer dial a realwss://chatgpt.comWebSocket before the mocked fetch, which is what made the success-control case time out. Closing manually because GitHub only auto-closes frommain; reopen if it recurs on currentdev.