This fixes issue #14113 where setHeader(['first', 'second']) was
returning 'first, second' instead of ['first', 'second'] in getHeaders().
Root cause:
- setHeader was converting arrays to joined strings for all purposes
- Node.js preserves arrays in getHeaders() but joins them for HTTP transmission
- Missing array preservation and proper copying for returned values
Changes:
- Modified OutgoingMessage.setHeader to preserve arrays in kOutHeaders
- Updated getHeaders() to return stored array/string values instead of Headers.toJSON()
- Added proper array copying to prevent reference sharing
- Updated removeHeader to clean both Headers and kOutHeaders
- Maintained HTTP transmission behavior (arrays still joined with ", ")
Tests:
- Added comprehensive regression tests covering all edge cases
- Tests array preservation, string handling, copying behavior
- Tests validation, case insensitivity, removal, and HTTP transmission
- Original failing test now correctly fails (indicating fix works)
Before:
setHeader('test', ['a', 'b'])
getHeaders() => { test: 'a, b' } // ❌ String
After:
setHeader('test', ['a', 'b'])
getHeaders() => { test: ['a', 'b'] } // ✅ Array (matches Node.js)
This improves Node.js compatibility for HTTP header handling, which is
important for libraries that depend on proper header array behavior.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Summary
- Adds `Symbol.asyncIterator` to `process.stdout` and `process.stderr`
when they are TTY or pipe/socket streams
- Matches Node.js behavior where these streams are Duplex-like and
support async iteration
- Does not add the iterator when streams are redirected to files
(matching Node.js SyncWriteStream behavior)
## Test plan
- Added test in
`test/regression/issue/test-process-stdout-async-iterator.test.ts`
- Verified the fix works with Claude Code on Linux x64
- Test passes with `bun bd test
test/regression/issue/test-process-stdout-async-iterator.test.ts`
Fixes#21704🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
- Fix transpiler bug where comma expressions like `(0, obj.method)()`
were incorrectly optimized to `obj.method()`
- This preserved the `this` binding instead of stripping it as per
JavaScript semantics
- Add comprehensive regression test to prevent future issues
## Root Cause
The comma operator optimization in `src/js_parser.zig:7281` was directly
returning the right operand when the left operand had no side effects,
without checking if the expression was being used as a call target.
## Solution
- Added the same `is_call_target` check that other operators (nullish
coalescing, logical OR/AND) use
- When a comma expression is used as a call target AND the right operand
has a value for `this`, preserve the comma expression to strip the
`this` binding
- Follows existing patterns in the codebase for consistent behavior
## Test Plan
- [x] Reproduce the original bug: `(0, obj.method)()` incorrectly
preserved `this`
- [x] Verify fix: comma expressions now correctly strip `this` binding
in function calls
- [x] All existing transpiler tests continue to pass
- [x] Added regression test covering various comma expression scenarios
- [x] Tested edge cases: nested comma expressions, side effects,
different operand types
🤖 Generated with [Claude Code](https://claude.ai/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>
## Summary
This PR fixes a bug in Bun's bundler where cyclic imports with async
dependencies would produce invalid JavaScript with syntax errors.
## Problem
When modules have cyclic imports and one uses top-level await, the
bundler wasn't properly marking all modules in the cycle as async. This
resulted in non-async wrapper functions containing `await` statements,
causing syntax errors like:
```
error: "await" can only be used inside an "async" function
```
## Solution
The fix matches esbuild's approach by calling `validateTLA` for all
files before `scanImportsAndExports` begins. This ensures async status
is properly propagated through import chains before dependency
resolution.
Key changes:
1. Added a new phase that validates top-level await for all parsed
JavaScript files before import/export scanning
2. This matches esbuild's `finishScan` function which processes all
files in source index order
3. Ensures the `is_async_or_has_async_dependency` flag is properly set
for all modules in cyclic import chains
## Test Plan
- Fixed the reproduction case provided in
`/Users/dylan/clones/bun-esm-bug`
- All existing bundler tests pass, including
`test/bundler/esbuild/default.test.ts`
- The bundled output now correctly generates async wrapper functions
when needed
fixes#21113🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Fixes#12276: toIncludeRepeated should check for the exact repeat count
not >=
This is a breaking change because some people may be relying on the
existing behaviour. Should it be feature-flagged for 1.3?
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
Fixes the "index out of bounds: index 0, len 0" crash that occurs during
large batch PostgreSQL inserts, particularly on Windows systems.
The issue occurred when PostgreSQL DataRow messages contained data but
the `statement.fields` array was empty (len=0), causing crashes in
`DataCell.Putter.putImpl()`. This typically happens during large batch
operations where there may be race conditions or timing issues between
RowDescription and DataRow message processing.
## Changes
- **Add bounds checking** in `DataCell.Putter.putImpl()` before
accessing `fields` and `list` arrays
(src/sql/postgres/DataCell.zig:1043-1050)
- **Graceful degradation** - return `false` to ignore extra fields
instead of crashing
- **Debug logging** to help diagnose field metadata issues
- **Comprehensive regression tests** covering batch inserts, empty
results, and concurrent operations
## Test Plan
- [x] Added regression tests in `test/regression/issue/21311.test.ts`
- [x] Tests pass with the fix: All 3 tests pass with 212 expect() calls
- [x] Existing PostgreSQL tests still work (no regressions)
The fix prevents the crash while maintaining safe operation, allowing
PostgreSQL batch operations to continue working reliably.
## Root Cause
The crash occurred when:
1. `statement.fields` array was empty (len=0) due to timing issues
2. PostgreSQL DataRow messages contained actual data
3. Code tried to access `this.list[index]` and `this.fields[index]`
without bounds checking
This was particularly problematic on Windows during batch operations due
to potential differences in:
- Network stack message ordering
- Memory allocation behavior
- Threading/concurrency during batch operations
- Statement preparation timing
Fixes#21311🤖 Generated with [Claude Code](https://claude.ai/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: Ciro Spaciari <ciro.spaciari@gmail.com>
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: 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>
