[Bug]: Windows GUI DST child passes but its parent times out on Bun 1.4.4
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- bun, typescript
- Domain
- testing
Research direction
Reproduce with bun --no-env-file --no-install ../scripts/test-with-pinned-bun.ts --isolate --timeout 60000 tests/usage-custom-range.test.tsx from gui to see parent timeout at gui/tests/usage-custom-range.test.tsx:300. Inspect the spawnSync and child deadlines in scripts/test-with-pinned-bun.ts and the nested test case. Done means the parent stops timing out while the Santiago DST assertions still pass.
Written by the indexing model from the issue text.
Description
Client or integration
Other — GUI test runner; no live provider request.
Area
Platform (Windows / macOS / Linux)
Summary
On unmodified dev, the Santiago DST regression prints its completion marker and passes eight assertions, but the parent reports exitedDueToTimeout: true at the existing 12-second child deadline. The whole file finishes with 37 passed, 1 failed, 479 assertions.
This reproduces a failure also observed while validating #7420. It is not exclusive to that PR's integration candidate; the physical cause and any product-facing impact remain unconfirmed.
Reproduction
At commit 323a5e11772c38c15b271d23c7696c5947bb97da, with matching GUI dependencies and official Bun 1.4.4+38afee6c8, run from gui:
bun --no-env-file --no-install ../scripts/test-with-pinned-bun.ts --isolate --timeout 60000 tests/usage-custom-range.test.tsx
Run the entire file, including preceding cases. The parent recursion flag is unset and parent TZ is absent; the original nested case supplies TZ=America/Santiago. Isolated HOME/TEMP/cache paths were used. Runtime and test-runner pins were both 1.4.4.
The original child-test 10-second, spawnSync 12-second, and parent-test 15-second bounds were unchanged. No source instrumentation, timeout increase, forced exit or package upgrade was used for this control. This is one baseline reproduction, not a measured failure rate.
Version
OpenCodex dev 323a5e11772c38c15b271d23c7696c5947bb97da; official Bun 1.4.4 revision 38afee6c8.
Operating system
Windows 11 Pro x64, build 26300.
Provider and model
Not applicable.
Logs or error output
Failing case: America/Santiago midnight DST retains final-day activity and tooltip, gui/tests/usage-custom-range.test.tsx:300.
- Nested output:
OCX_SANTIAGO_CASE_COMPLETED, 1 passed / 8 assertions, 734 ms test summary. - Parent:
exitedDueToTimeoutwas true; elapsed 12,093 ms. - Entire file: 37 passed / 1 failed / 479 assertions.
- The outer wrapper naturally exited 1, both streams reached EOF, and no direct children remained. Its 68.05-second elapsed time and Bun's 33.53-second file summary are separate timing domains.
Nested body success does not prove process termination or pipe completion. The original synchronous fixture does not expose those nested timestamps.
Screenshots and supporting files
Text-only test failure. A separately instrumented child under a .NET observer exited successfully in about 1.04 seconds; a private Bun.spawn replacement still exceeded the same 12-second deadline. Neither is an adopted fix or proof of cause.
#4956 records an older child-process issue fixed in Bun 1.4.3. This observation uses 1.4.4; a shared cause is unconfirmed. The next diagnostic should distinguish nested process exit from pipe completion while preserving the DST assertions and deadlines.
Redacted configuration
Not applicable; no provider, account or trust configuration was changed.
Checks
- I searched existing issues and documentation.
- I removed secrets, tokens, account details, request credentials, and personal data.
- Dominant language
- TypeScript
- Stars
- 16.9k
- Forks
- 1.3k
- Avg merge
- 9h 39m
- Merged PRs (30d)
- 633
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from lidge-jun/opencodex
-
catalog enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
lidge-jun/opencodex#7704 · 1 comment ·
Maintainers usually reply within 1 day
-
bug streaming
Difficulty 4/5 3-5 days Newbie friendliness 35/100
lidge-jun/opencodex#7720 · 2 comments ·
Maintainers usually reply within 1 day
-
account-pool provider provider-compatibility
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 1 day
-
catalog enhancement
Difficulty 5/5 Over a week Newbie friendliness 30/100
lidge-jun/opencodex#7705 · 1 comment ·
Maintainers usually reply within 1 day
-
bug catalog
Difficulty 4/5 3-5 days Newbie friendliness 55/100
lidge-jun/opencodex#7703 · 2 comments ·
Maintainers usually reply within 1 day
All issues in lidge-jun/opencodex
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 70/100
microsoft/playwright#43640 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
grasshopper-protocol/grsshppr#172 ·
Maintainers usually reply within 1 day
-
bug help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Tencent/teamai-cli#1397 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
DouyinFE/semi-design#3641 ·
Maintainers usually reply within 3 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day