fix(windows): prevent data loss in pipe reads after libuv 1.51.0 upgrade (#23340)

### What does this PR do?

Fixes data loss when reading large amounts of data from subprocess pipes
on Windows, a regression introduced by the libuv 1.51.0 upgrade in
commit e3783c244f.

### The Problem

When piping large data through a subprocess on Windows (e.g.,
`process.stdin.pipe(process.stdout)`), Bun randomly loses ~73KB of data
out of 1MB, receiving only ~974KB instead of the full 1048576 bytes.

The subprocess correctly receives all 1MB on stdin, but the parent
process loses data when reading from the subprocess stdout.

### Root Cause Analysis

#### libuv 1.51.0 Change

The libuv 1.51.0 upgrade (commit
[libuv/libuv@727ee723](727ee7237e))
changed Windows pipe reading behavior:

**Before:** libuv would call `PeekNamedPipe` to check available bytes,
then read exactly that amount.

**After:** libuv attempts immediate non-blocking reads (up to 65536
bytes) before falling back to async reads. If less data is available
than requested, it returns what's available and signals `more=0`,
causing the read loop to break.

This optimization introduces **0-byte reads** when data isn't
immediately available, which are delivered to Bun's read callback.

#### The Race Condition

When Bun's `WindowsBufferedReader` called `onRead(.drained)` for these
0-byte reads, it created a race condition. Debug logs clearly show the
issue:

**Error case (log.txt):**
```
Line 79-80: onStreamRead = 0 (drained)
Line 81:    filesink closes (stdin closes)
Line 85:    onStreamRead = 6024        ← Should be 74468!
Line 89:    onStreamRead = -4095 (EOF)
```

**Success case (success.log.txt):**
```
Line 79-80: onStreamRead = 0 (drained)
Line 81:    filesink closes (stdin closes)
Line 85:    onStreamRead = 74468       ← Full chunk!
Line 89-90: onStreamRead = 0 (drained)
Line 91:    onStreamRead = 6024
Line 95:    onStreamRead = -4095 (EOF)
```

When stdin closes while a 0-byte drained read is pending, the next read
returns truncated data (6024 bytes instead of 74468 bytes).

### The Fix

Two changes to `WindowsBufferedReader` in `src/io/PipeReader.zig`:

#### 1. Ignore 0-byte reads (line 937-940)

Don't call `onRead(.drained)` for 0-byte reads. Just return and let
libuv queue the next read. This prevents the race condition that causes
truncated reads.

```zig
0 => {
    // With libuv 1.51.0+, calling onRead(.drained) here causes a race condition
    // where subsequent reads return truncated data. Just ignore 0-byte reads.
    return;
},
```

#### 2. Defer `has_inflight_read` flag clearing (line 827-839)

Clear the flag **after** the read callback completes, not before. This
prevents libuv from starting a new overlapped read operation while we're
still processing the current data buffer, which could cause memory
corruption per the libuv commit message:

> "Starting a new read after uv_read_cb returns causes memory corruption
on the OVERLAPPED read_req if uv_read_stop+uv_read_start was called
during the callback"

```zig
const result = onReadChunkFn(this.parent, buf, hasMore);
// Clear has_inflight_read after the callback completes
this.flags.has_inflight_read = false;
return result;
```

### How to Test

Run the modified test in
`test/js/bun/spawn/spawn-stdin-readable-stream.test.ts`:

```js
test("ReadableStream with very large chunked data", async () => {
  const chunkSize = 64 * 1024; // 64KB chunks
  const numChunks = 16; // 1MB total
  const chunk = Buffer.alloc(chunkSize, "x");

  const stream = new ReadableStream({
    pull(controller) {
      if (pushedChunks < numChunks) {
        controller.enqueue(chunk);
        pushedChunks++;
      } else {
        controller.close();
      }
    },
  });

  await using proc = spawn({
    cmd: [bunExe(), "-e", `
      let length = 0;
      process.stdin.on('data', (data) => length += data.length);
      process.once('beforeExit', () => console.error(length));
      process.stdin.pipe(process.stdout)
    `],
    stdin: stream,
    stdout: "pipe",
    env: bunEnv,
  });

  const text = await proc.stdout.text();
  expect(text.length).toBe(chunkSize * numChunks); // Should be 1048576
});
```

**Before fix:** Randomly fails with ~974KB instead of 1MB  
**After fix:** Consistently passes with full 1MB

Run ~100 times to verify the race condition is fixed.

### Related Issues

This may also fix #23071 (Windows scripts hanging), though that issue
needs separate verification.

### Why Draft?

Marking as draft for Windows testing by the team. The fix is based on
detailed debug log analysis showing the exact race condition, but needs
verification on Windows CI.

🤖 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: Jarred Sumner <jarred@jarredsumner.com>

src/bun.js/webcore/FileSink.zig

@@ -62,12 +62,33 @@ pub fn memoryCost(this: *const FileSink) usize {
 
 fn Bun__ForceFileSinkToBeSynchronousForProcessObjectStdio(_: *jsc.JSGlobalObject, jsvalue: jsc.JSValue) callconv(.C) void {
     var this: *FileSink = @alignCast(@ptrCast(JSSink.fromJS(jsvalue) orelse return));
-    this.force_sync = true;
+
     if (comptime !Environment.isWindows) {
+        this.force_sync = true;
         this.writer.force_sync = true;
         if (this.fd != bun.invalid_fd) {
             _ = bun.sys.updateNonblocking(this.fd, false);
         }
+    } else {
+        if (this.writer.source) |*source| {
+            switch (source.*) {
+                .pipe => |pipe| {
+                    if (uv.uv_stream_set_blocking(@ptrCast(pipe), 1) == .zero) {
+                        return;
+                    }
+                },
+                .tty => |tty| {
+                    if (uv.uv_stream_set_blocking(@ptrCast(tty), 1) == .zero) {
+                        return;
+                    }
+                },
+
+                else => {},
+            }
+        }
+
+        // Fallback to WriteFile() if it fails.
+        this.force_sync = true;
     }
 }
 

src/io/PipeReader.zig

@@ -824,13 +824,19 @@ pub const WindowsBufferedReader = struct {
 
     fn _onReadChunk(this: *WindowsBufferedReader, buf: []u8, hasMore: ReadState) bool {
         if (this.maxbuf) |m| m.onReadBytes(buf.len);
-        this.flags.has_inflight_read = false;
         if (hasMore == .eof) {
             this.flags.received_eof = true;
         }
 
-        const onReadChunkFn = this.vtable.onReadChunk orelse return true;
-        return onReadChunkFn(this.parent, buf, hasMore);
+        const onReadChunkFn = this.vtable.onReadChunk orelse {
+            this.flags.has_inflight_read = false;
+            return true;
+        };
+        const result = onReadChunkFn(this.parent, buf, hasMore);
+        // Clear has_inflight_read after the callback completes to prevent
+        // libuv from starting a new read while we're still processing data
+        this.flags.has_inflight_read = false;
+        return result;
     }
 
     fn finish(this: *WindowsBufferedReader) void {
@@ -928,7 +934,10 @@ pub const WindowsBufferedReader = struct {
         switch (nread_int) {
             0 => {
                 // EAGAIN or EWOULDBLOCK or canceled  (buf is not safe to access here)
-                return this.onRead(.{ .result = 0 }, "", .drained);
+                // With libuv 1.51.0+, calling onRead(.drained) here causes a race condition
+                // where subsequent reads return truncated data (see logs showing 6024 instead
+                // of 74468 bytes). Just ignore 0-byte reads and let libuv continue.
+                return;
             },
             uv.UV_EOF => {
                 _ = this.stopReading();

test/js/bun/spawn/spawn-stdin-readable-stream.test.ts

@@ -169,11 +169,12 @@ describe("spawn stdin ReadableStream", () => {
     const chunkSize = 64 * 1024; // 64KB chunks
     const numChunks = 16; // 1MB total
     let pushedChunks = 0;
+    const chunk = Buffer.alloc(chunkSize, "x");
 
     const stream = new ReadableStream({
       pull(controller) {
         if (pushedChunks < numChunks) {
-          controller.enqueue("x".repeat(chunkSize));
+          controller.enqueue(chunk);
           pushedChunks++;
         } else {
           controller.close();
@@ -182,7 +183,16 @@ describe("spawn stdin ReadableStream", () => {
     });
 
     await using proc = spawn({
-      cmd: [bunExe(), "-e", "process.stdin.pipe(process.stdout)"],
+      cmd: [
+        bunExe(),
+        "-e",
+        `
+        let length = 0;
+        process.stdin.on('data', (data) => length += data.length);
+        process.once('beforeExit', () => console.error(length));
+        process.stdin.pipe(process.stdout)
+`,
+      ],
       stdin: stream,
       stdout: "pipe",
       env: bunEnv,
@@ -190,7 +200,7 @@ describe("spawn stdin ReadableStream", () => {
 
     const text = await proc.stdout.text();
     expect(text.length).toBe(chunkSize * numChunks);
-    expect(text).toBe("x".repeat(chunkSize * numChunks));
+    expect(text).toBe(chunk.toString().repeat(numChunks));
     expect(await proc.exited).toBe(0);
   });
 

test/regression/issue/11297/11297.fixture.ts

@@ -4,7 +4,16 @@ const string = Buffer.alloc(1024 * 1024, "zombo.com\n").toString();
 process.exitCode = 1;
 
 const proc = Bun.spawn({
-  cmd: [bunExe(), "-e", "process.stdin.pipe(process.stdout)"],
+  cmd: [
+    bunExe(),
+    "-e",
+    `
+let length = 0;
+process.stdin.on('data', (data) => length += data.length);
+process.once('beforeExit', () => console.error(length));
+process.stdin.pipe(process.stdout)
+    `,
+  ],
   stdio: ["pipe", "pipe", "inherit"],
 });