The nested child Bun process should also use --autokill to properly test
the nested autokill behavior. This ensures both the parent and child Bun
processes will kill their children when exiting.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add test case for nested Bun processes to verify that the three-pass
autokill strategy with delays correctly handles:
1. A parent Bun process spawning a child Bun process
2. The child Bun process spawning its own children (sleep)
3. All processes being properly killed when the parent exits
This addresses the review comment requesting tests for nested Bun
processes specifically because of the delay timing in the three-pass
strategy.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Remove early returns when children.len == 0 that were aborting the
entire autokill sequence. Now treat empty slices as "nothing to do this
pass" and continue to the next pass, allowing later passes to retry
enumeration and send SIGSTOP/SIGKILL as intended.
This fixes the case where enumeration failures (which return empty
slices) would prevent subsequent passes from running, potentially
leaving processes alive.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Use std.os.linux.kill() directly on Linux instead of std.c.kill() to
bypass potential musl libc issues where processes were not being killed
properly during the three-pass autokill sequence.
Tests were failing on musl/Alpine showing processes still alive after
autokill. Direct syscalls avoid any libc wrapper issues.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Added comprehensive documentation explaining the three-pass approach:
Why Three Passes:
1. SIGTERM first: Allows graceful cleanup (close files, flush buffers)
- Most processes (60-80%) exit here
- Early bailout makes this faster in practice
2. SIGSTOP second: Freeze survivors to prevent reparenting races
- Maintains the race-safety from original two-pass design
- Fresh enumeration catches any children spawned after SIGTERM
3. SIGKILL third: Force termination of frozen processes
- Ensures nothing survives
- Cannot be caught or ignored
The three-pass strategy is superior to the original two-pass (SIGSTOP→SIGKILL):
- More graceful: Allows cleanup handlers
- Better performance: Early bailout when processes respect SIGTERM
- Still safe: SIGSTOP prevents races
- More thorough: Fresh enumeration between each pass
All 13 tests pass. Strategy was explicitly requested during implementation.
Changed from hardcoded musl detection to graceful fallback:
- Try /proc/{pid}/task/{tid}/children first (fast path)
- If it fails for ANY reason, fall back to /proc scanning
- Works on all systems: glibc, musl, old kernels, Alpine, etc.
Why this is better:
- No assumptions about musl behavior
- Automatically handles kernel differences
- /proc/{pid}/task/{tid}/children works on Alpine if available
- Falls back gracefully if not
- Simpler code without platform-specific branches
This should fix the musl test failures by letting the system tell us
what works rather than guessing based on libc implementation.
Added guard to skip autokill when may_return=true (crash handler path).
Why:
- killAllChildProcesses performs heap allocations (AutoHashMap, getChildPids)
- Makes syscalls (/proc reads, kill() calls)
- In a crash handler context, the process state may be compromised
- Additional allocations/syscalls could hang or cause cascading failures
Now autokill only runs during normal reloads (!may_return), not during
crash recovery where process state may be unstable.
This ensures autokill doesn't make a bad situation worse during crashes.
Improvements:
1. Reduced delay from 10ms to 500 microseconds (20x faster)
- Still enough time for processes to handle SIGTERM
- Much faster exit in the common case
2. Fresh child enumeration per pass
- Don't keep stale PIDs around between passes
- Each pass gets current state of process tree
- Scoped blocks ensure immediate cleanup of allocations
3. Early bailout optimization
- Return immediately if no children found in Pass 1
- Skip Pass 2 if all children exited from SIGTERM
- Skip Pass 3 if all children exited from SIGSTOP
Benefits:
- Faster: 500us delay instead of 10ms
- More accurate: Fresh child list each pass
- More efficient: Skip unnecessary passes when children exit early
- Cleaner memory: Scoped blocks free resources immediately
Changed from two-pass to three-pass strategy:
Pass 1: SIGTERM - Give processes a chance to handle graceful cleanup
- Allows signal handlers to run
- 10ms delay to process cleanup work
Pass 2: SIGSTOP - Freeze remaining processes to prevent reparenting
- Stops processes that didn't exit from SIGTERM
- Prevents race conditions during tree traversal
Pass 3: SIGKILL - Force termination of any remaining processes
- Ensures all processes are killed
- Cannot be caught or ignored
Benefits:
- More graceful: Processes get a chance to clean up (close files, flush buffers)
- More reliable: SIGSTOP prevents reparenting races
- Still thorough: SIGKILL ensures nothing escapes
The enum-based approach (.sigterm, .sigstop, .sigkill) is clearer than the
previous boolean 'stop_only' parameter.
Wire up autokill to run at the start of reloadProcess() (before execve).
This ensures that when --watch or --hot triggers a reload, any spawned child
processes are cleaned up before the process restarts.
Benefits:
- Clean state on reload: no orphaned processes
- Consistent behavior: autokill works on both normal exit AND reload
- Prevents process leaks during development with --watch
The autokill happens after reload flags are set but before terminal reset,
ensuring processes are killed early in the reload sequence.
In killProcessTreeRecursive, if getChildPids fails (e.g., transient /proc read
failures, race conditions), we were returning early without sending any signals
to that PID, allowing that branch of the process tree to survive.
Now we treat enumeration failures as "no children" and continue to send
SIGSTOP/SIGTERM/SIGKILL to the process itself. This ensures we always attempt
to kill the process even if we can't enumerate its children, making autokill
more reliable under adverse conditions.
Previously, if /proc/{pid}/task/{tid}/children could be opened but not read
(e.g., unreadable or >4096 bytes), we returned an empty list instead of
falling back to the /proc scan. This was inconsistent with file-open failures
which properly fell back.
Now all read failures trigger the same fallback path, ensuring we always
attempt to find children even when the fast path fails.
CRITICAL FIX: bun.SignalCode enum has hardcoded Linux signal values, which
breaks on macOS where signals have different numbers:
- Linux: SIGSTOP=19, SIGTERM=15, SIGKILL=9
- macOS: SIGSTOP=17, SIGTERM=15, SIGKILL=9
Changed from:
- @intFromEnum(bun.SignalCode.SIGSTOP) // Always 19
To:
- std.posix.SIG.STOP // 17 on macOS, 19 on Linux
std.posix.SIG provides platform-specific signal constants that automatically
use the correct values for each OS via the Zig standard library's platform
detection. This ensures:
1. SIGSTOP actually freezes processes on macOS (not SIGTSTP which is catchable)
2. The two-pass freeze-then-kill strategy works correctly on all platforms
3. No platform-specific conditional code needed
Replaced hardcoded signal numbers (19, 15, 9) with bun.SignalCode enum:
- SIGSTOP (was 19): Correct on all platforms, avoiding Linux-specific assumptions
- SIGTERM (was 15): Consistent across platforms
- SIGKILL (was 9): Guaranteed termination signal
This fixes a critical bug on macOS where signal 19 is SIGTSTP (stoppable via
signal handler) instead of SIGSTOP, which would break the freeze-then-kill
two-pass strategy. Using bun.SignalCode ensures correct signal values across
all supported platforms.
1. Allow pass 2 to continue even if pass 1 fails: Changed early returns to
return empty slices so that if child enumeration fails in pass 1, we still
attempt termination in pass 2. This makes the two-pass strategy more robust.
2. Better allocation failure handling: When allocPrint fails in getChildPids,
fall back to /proc scanning instead of returning an empty list. This
distinguishes between "no children" and "allocation failed".
3. Document macOS buffer limitation: Added comment explaining the 2048 child
limit on macOS and why it's acceptable for autokill's use case.
These changes ensure autokill attempts termination even under adverse
conditions like memory pressure or /proc read errors.
The code now properly implements the two-pass strategy:
1. Pass 1: Send SIGSTOP to freeze the entire process tree and minimize reparenting races
2. Pass 2: Send SIGTERM followed by SIGKILL to terminate all frozen processes
Each pass uses its own visited set (seen_stop, seen_kill) to track processed PIDs.
This prevents race conditions where child processes might reparent to init during cleanup.
- Only call autokill on main thread to avoid killing children during worker teardown
- Remove process group kill (-pid) that was killing Bun itself before shutdown
- Add Windows platform guards to skip Unix-specific autokill tests
Fixes:
1. VirtualMachine.onExit now checks isMainThread() before calling killAllChildProcesses
2. autokill.zig no longer uses kill(-pid) which killed Bun's own process
3. test/cli/autokill.test.ts now skips on Windows with describe.skipIf(isWindows)
Resolved conflicts:
- src/cli/Arguments.zig: Added both --autokill and --user-agent flags, merged CA store logic
- src/sys.zig: Imported both autokill and PosixStat modules
- cmake/sources/ZigSources.txt: Removed as deleted in main
## Summary
The `bun outdated` command now displays catalog dependencies with their
workspace grouping even when run without the `--filter` or `-r` flags.
## What changed
- Added detection for catalog dependencies in the outdated packages list
- The workspace column is now shown when:
- Using `--filter` or `-r` flags (existing behavior)
- OR when there are catalog dependencies to display (new behavior)
- When there are no catalog dependencies and no filtering, the workspace
column remains hidden as before
## Why
Previously, running `bun outdated` without any flags would not show
which workspaces were using catalog dependencies, making it unclear
where catalog entries were being used. This fix ensures catalog
dependencies are properly grouped and displayed with their workspace
information.
## Test
```bash
# Create a workspace project with catalog dependencies
mkdir test-catalog && cd test-catalog
cat > package.json << 'JSON'
{
"name": "test-catalog",
"workspaces": ["packages/*"],
"catalog": {
"react": "^17.0.0"
}
}
JSON
mkdir -p packages/{app1,app2}
echo '{"name":"app1","dependencies":{"react":"catalog:"}}' > packages/app1/package.json
echo '{"name":"app2","dependencies":{"react":"catalog:"}}' > packages/app2/package.json
bun install
bun outdated # Should now show catalog grouping without needing --filter
```
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
## Summary
During `yarn.lock` migration, OS/CPU package metadata was not being
fetched from the npm registry when missing from `yarn.lock`. This caused
packages with platform-specific requirements to not be properly marked,
potentially leading to incorrect package installation behavior.
## Changes
Updated `fetchNecessaryPackageMetadataAfterYarnOrPnpmMigration` to
conditionally fetch OS/CPU metadata:
- **For yarn.lock migration**: Fetches OS/CPU metadata from npm registry
when not present in yarn.lock (`update_os_cpu = true`)
- **For pnpm-lock.yaml migration**: Skips OS/CPU fetching since
pnpm-lock.yaml already includes this data (`update_os_cpu = false`)
### Files Modified
- `src/install/lockfile.zig` - Added comptime `update_os_cpu` parameter
and conditional logic to fetch OS/CPU metadata
- `src/install/yarn.zig` - Pass `true` to enable OS/CPU fetching for
yarn migrations
- `src/install/pnpm.zig` - Pass `false` to skip OS/CPU fetching for pnpm
migrations (already parsed from lockfile)
## Why This Approach
- `yarn.lock` format often doesn't include OS/CPU constraints, requiring
us to fetch from npm registry
- `pnpm-lock.yaml` already parses OS/CPU during migration (lines 618-621
in pnpm.zig), making additional fetching redundant
- Using a comptime parameter allows the compiler to optimize away the
unused code path
## Testing
- ✅ Debug build compiles successfully
- Tested that the function correctly updates `pkg_meta.os` and
`pkg_meta.arch` only when:
- `update_os_cpu` is `true` (yarn migration)
- Current values are `.all` (not already set)
- Package metadata is available from npm registry
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Dylan Conway <dylan.conway567@gmail.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
Added Claude Code hooks to prevent common development mistakes when
working on the Bun codebase.
## Changes
- Created `.claude/hooks/pre-bash-zig-build.js` - A pre-bash hook that
validates commands
- Created `.claude/settings.json` - Hook configuration
## Prevented Mistakes
1. **Running `zig build obj` directly** → Redirects to use `bun bd`
2. **Using `bun test` in development** → Must use `bun bd test` (or set
`USE_SYSTEM_BUN=1`)
3. **Combining snapshot updates with test filters** → Prevents
`-u`/`--update-snapshots` with `-t`/`--test-name-pattern`
4. **Running `bun bd` with timeout** → Build needs time to complete
without timeout
5. **Running `bun bd test` from repo root** → Must specify a test file
path to avoid running all tests
## Test plan
- [x] Tested all validation rules with various command combinations
- [x] Verified USE_SYSTEM_BUN=1 bypass works
- [x] Verified file path detection works correctly
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
## Summary
- Adds birthtime (file creation time) support on Linux using the `statx`
syscall
- Stores birthtime in architecture-specific unused fields of the kernel
Stat struct (x86_64 and aarch64)
- Falls back to traditional `stat` on kernels < 4.11 that don't support
`statx`
- Includes comprehensive tests validating birthtime behavior
Fixes#6585
## Implementation Details
**src/sys.zig:**
- Added `StatxField` enum for field selection
- Implemented `statxImpl()`, `fstatx()`, `statx()`, and `lstatx()`
functions
- Stores birthtime in unused padding fields (architecture-specific for
x86_64 and aarch64)
- Graceful fallback to traditional stat if statx is not supported
**src/bun.js/node/node_fs.zig:**
- Updated `stat()`, `fstat()`, and `lstat()` to use statx functions on
Linux
**src/bun.js/node/Stat.zig:**
- Added `getBirthtime()` helper to extract birthtime from
architecture-specific storage
**test/js/node/fs/fs-birthtime-linux.test.ts:**
- Tests non-zero birthtime values
- Verifies birthtime immutability across file modifications
- Validates consistency across stat/lstat/fstat
- Tests BigInt stats with nanosecond precision
- Verifies birthtime ordering relative to other timestamps
## Test Plan
- [x] Run `bun bd test test/js/node/fs/fs-birthtime-linux.test.ts` - all
5 tests pass
- [x] Compare behavior with Node.js - identical behavior
- [x] Compare with system Bun - system Bun returns epoch, new
implementation returns real birthtime
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Packages with self dependencies at a different version were colliding
with the current version in the store node_modules. This pr nests them
in another node_modules
Example:
self-dep@1.0.2 has a dependency on self-dep@1.0.1.
self-dep@1.0.2 is placed here in:
`./node_modules/.bun/self-dep@1.0.2/node_modules/self-dep`
and it's self-dep dependency symlink is now placed in:
`./node_modules/.bun/self-dep@1.0.2/node_modules/self-dep/node_modules/self-dep`
fixes#22681
### How did you verify your code works?
Manually tested the linked issue is working, and added a test
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Enable compiler flags
Update SQLite amalgamation using https://www.sqlite.org/download.html
source code
[sqlite-src-3500400.zip](https://www.sqlite.org/2025/sqlite-src-3500400.zip)
with:
```bash
./configure CFLAGS="-DSQLITE_ENABLE_UPDATE_DELETE_LIMIT"
make sqlite3.c
```
This is the same version that before just with this adicional flag that
must be enabled when generating the amalgamation so we are actually able
to use this option. You can also see that without this the build will
happen but the feature will not be enable
https://buildkite.com/bun/bun/builds/27940, as informed in
https://www.sqlite.org/howtocompile.html topic 5.
### How did you verify your code works?
Add in CI two tests that check if the feature is enabled on windows
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
### What does this PR do?
Bun sometimes crashes with a segmentation fault while generating stack
traces.
the following might be happening in `remapZigException`:
1. The first populateStackTrace (OnlyPosition) sets `frames_len` (e.g.,
frames_len = 5)
613aea1787/src/bun.js/bindings/bindings.cpp (L4793)
```
[frame1, frame2, frame3, frame4, frame5]
```
2. Frame filtering in remapZigException reduces `frames_len` (e.g.,
frames_len = 3)
613aea1787/src/bun.js/VirtualMachine.zig (L2686-L2704)
```
[frame1, frame4, frame5, (frame4, frame5)]
// frame2 and frame3 are removed by filtering; frames_len is set to 3 here, but frame4 and frame5 remain in their original positions
```
3. The second populateStackTrace (OnlySourceLine) increases `frames_len`
(e.g., frames_len = 5)
613aea1787/src/bun.js/bindings/bindings.cpp (L4793)
```
[frame1, frame4, frame5, frame4, frame5]
```
When deinit is executed on these frames, the ref count is excessively
decremented (for frame4 and frame5), resulting in a UAF.
### How did you verify your code works?
WIP. I'm working on creating minimal reproduction code.
However, I've confirmed that `twenty-server` tests passes with this PR.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
## Summary
Increase the stack trace buffer size in the crash handler from 10 to 20
frames to ensure more useful frames are included in crash reports sent
to bun.report.
## Motivation
Currently, we capture up to 10 stack frames when generating crash
reports. However, many of these frames get filtered out when
`StackLine.fromAddress()` returns `null` for invalid/empty frames. This
results in only a small number of frames (sometimes as few as 5)
actually being sent to the server.
## Changes
- Increased `addr_buf` array size from `[10]usize` to `[20]usize` in
`src/crash_handler.zig:307`
## Impact
By capturing more frames initially, we ensure that after filtering we
still have a meaningful number of frames in the crash report. This will
help with debugging crashes by providing more context about the call
stack.
The encoding function `encodeTraceString()` has no hardcoded limits and
will encode all available frames, so this change directly translates to
more frames being sent to bun.report.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
### What does this PR do?
Parsing would fail because the lockfile version might be parsing as a
non-whole float instead of a string (`5.4` vs `'5.4'`) and the migration
would have the wrong error.
### How did you verify your code works?
Added a test
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
### What does this PR do?
It's common for monorepos to exclude portions of a large glob
```json
"workspaces": [
"packages/**",
"!packages/**/test/**",
"!packages/**/template/**"
],
```
closes#4621 (note: patterns like `"packages/!(*-standalone)"` will need
to be written `"!packages/*-standalone"`)
### How did you verify your code works?
Manually tested https://github.com/opentiny/tiny-engine, and added a new
workspace test.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Add `jsc.DecodedJSValue`, an extern struct which is ABI-compatible with
`JSC::JSValue`. (By contrast, `jsc.JSValue` is ABI-compatible with
`JSC::EncodedJSValue`.) This enables `jsc.Strong.get` to be more
efficient: it no longer has to call into C++.
(For internal tracking: fixes ENG-20748)
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Returning clause should work with insert now
### How did you verify your code works?
Tests
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
Split `JSNodeHTTPServerSocket` and `JSNodeHTTPServerSocketPrototype`
from `NodeHTTP.cpp` into dedicated files, following the same pattern as
`JSDiffieHellman` in the crypto module.
## Changes
- **Created 4 new files:**
- `JSNodeHTTPServerSocket.h` - Class declaration
- `JSNodeHTTPServerSocket.cpp` - Class implementation and methods
- `JSNodeHTTPServerSocketPrototype.h` - Prototype declaration
- `JSNodeHTTPServerSocketPrototype.cpp` - Prototype methods and property
table
- **Moved from NodeHTTP.cpp:**
- All custom getters/setters (onclose, ondrain, ondata, etc.)
- All host functions (close, write, end)
- Event handlers (onClose, onDrain, onData)
- Helper functions and templates
- **Preserved:**
- All extern C bindings for Zig interop
- All existing functionality
- Proper namespace and include structure
- **Merged changes from main:**
- Added `upgraded` flag for websocket support (from #23150)
- Updated `clearSocketData` to handle WebSocketData
- Added `onSocketUpgraded` callback handler
## Impact
- Reduced `NodeHTTP.cpp` from ~1766 lines to 1010 lines (43% reduction)
- Better code organization and maintainability
- No functional changes
## Test plan
- [x] Build compiles successfully
- [x] `test/js/node/http/node-http.test.ts` passes (72/74 tests pass,
same as before)
- [x] `test/js/node/http/node-http-with-ws.test.ts` passes (websocket
upgrade test)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Add a new generator for JS → Zig bindings. The bulk of the conversion is
done in C++, after which the data is transformed into an FFI-safe
representation, passed to Zig, and then finally transformed into
idiomatic Zig types.
In its current form, the new bindings generator supports:
* Signed and unsigned integers
* Floats (plus a “finite” variant that disallows NaN and infinities)
* Strings
* ArrayBuffer (accepts ArrayBuffer, TypedArray, or DataView)
* Blob
* Optional types
* Nullable types (allows null, whereas Optional only allows undefined)
* Arrays
* User-defined string enumerations
* User-defined unions (fields can optionally be named to provide a
better experience in Zig)
* Null and undefined, for use in unions (can more efficiently represent
optional/nullable unions than wrapping a union in an optional)
* User-defined dictionaries (arbitrary key-value pairs; expects a JS
object and parses it into a struct)
* Default values for dictionary members
* Alternative names for dictionary members (e.g., to support both
`serverName` and `servername` without taking up twice the space)
* Descriptive error messages
* Automatic `fromJS` functions in Zig for dictionaries
* Automatic `deinit` functions for the generated Zig types
Although this bindings generator has many features not present in
`bindgen.ts`, it does not yet implement all of `bindgen.ts`'s
functionality, so for the time being, it has been named `bindgenv2`, and
its configuration is specified in `.bindv2.ts` files. Once all
`bindgen.ts`'s functionality has been incorporated, it will be renamed.
This PR ports `SSLConfig` to use the new bindings generator; see
`SSLConfig.bindv2.ts`.
(For internal tracking: fixes STAB-1319, STAB-1322, STAB-1323,
STAB-1324)
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Alistair Smith <hi@alistair.sh>
### What does this PR do?
Replaces '.upgrade()' with '.cloneUpgrade()'. '.upgrade()' is confusing
and `.clone().upgrade()` was causing a leak. Caught by
https://github.com/oven-sh/bun/pull/23199#discussion_r2400667320
### How did you verify your code works?
## Summary
- Fixed crypto.hkdf callback to pass `null` instead of `undefined` for
the error parameter on success
- Added regression test to verify the fix
## Details
Fixes#23211
Node.js convention requires crypto callbacks to receive `null` as the
error parameter on success, but Bun was passing `undefined`. This caused
compatibility issues with code that relies on strict null checks (e.g.,
[matter.js](fdbec2cf88/packages/general/src/crypto/NodeJsStyleCrypto.ts (L169))).
### Changes
- Updated `CryptoHkdf.cpp` to pass `jsNull()` instead of `jsUndefined()`
for the error parameter in the success callback
- Added regression test in `test/regression/issue/23211.test.ts`
## Test plan
- [x] Added regression test that verifies callback receives `null` on
success
- [x] Test passes with the fix
- [x] Ran existing crypto tests (no failures)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Dylan Conway <dylan.conway567@gmail.com>
## Summary
Fixes a segmentation fault on Windows 11 when accessing `process.title`
in certain scenarios (e.g., when fetching system information or making
Discord webhook requests).
## Root Cause
The crash occurred in libuv's `uv_get_process_title()` at `util.c:413`
in the `strlen()` call. The issue is that `uv__get_process_title()`
could return success (0) but leave `process_title` as NULL in edge cases
where:
1. `GetConsoleTitleW()` returns an empty string
2. `uv__convert_utf16_to_utf8()` succeeds but doesn't allocate memory
for the empty string
3. The subsequent `assert(process_title)` doesn't catch this in release
builds
4. `strlen(process_title)` crashes with a null pointer dereference
## Changes
Added defensive checks in `BunProcess.cpp`:
1. Initialize the title buffer to an empty string before calling
`uv_get_process_title()`
2. Check if the buffer is empty after the call returns
3. Fall back to "bun" if the title is empty or the call fails
## Testing
Added regression test in `test/regression/issue/23183.test.ts` that
verifies:
- `process.title` doesn't crash when accessed
- Returns a valid string (either the console title or "bun")
Fixes#23183🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
### What does this PR do?
Fixes `file:.` in root package.json or `file:../..` in workspace
package.json (if '../..' points to the root of the project)
### How did you verify your code works?
Added a test
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
Replace `createJSBunRequestStructure()` call with direct access to the
cached structure in `JSBunRequest::clone()` method for better
performance.
## Changes
- Updated `JSBunRequest::clone()` to use
`m_JSBunRequestStructure.getInitializedOnMainThread()` instead of
calling `createJSBunRequestStructure()`
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
### What does this PR do?
Fixes#23120
bun:test changes introduced an added 16-100ms sleep between test files.
For a test suite with many fast-running test files, this caused
significant impact. Elysia's test suite was running 2x slower (1.8s →
3.9s).
<img width="646" height="289" alt="image"
src="https://github.com/user-attachments/assets/2ecd8c3e-984c-4a9a-a988-a911576b87c4"
/>
### How did you verify your code works?
Running elysia test suite & minimized reproduction case
<details>
<summary>Minimzed reproduction case</summary>
```ts
// full2.test.ts
import { it } from 'bun:test'
it("timeout", () => {
setTimeout(() => {}, 295000);
}, 0);
// bench.ts
import {$} from "bun";
await $`rm -rf tests`;
await $`mkdir -p tests`;
for (let i = 0; i < 128; i += 1) {
await Bun.write(`tests/${i}.test.ts`, `
for (let i = 0; i < 1000; i ++) {
it("test${i}", () => {}, 0);
}
`);
}
Bun.spawnSync({
cmd: ["hyperfine", ...["bun-1.2.22", "bun-1.2.23+wakeup", "bun-1.2.23"].map(v => `${v} test ./full2.test.ts tests`)],
stdio: ["inherit", "inherit", "inherit"],
});
```
</details>
### What does this PR do?
Fix --rerun-each. Fixes#21409
### How did you verify your code works?
Test case
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Time should be represented as HH:MM:SS or HHH:MM:SS string
### How did you verify your code works?
Test
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
