[stdio] Bun hangs reading from stdin pipeline at >= 16384 Bytes (16KiB)

[javalsai]

What version of Bun is running?

1.0.27+c34bbb2e3

What platform is your computer?

Linux 6.7.4-arch1-1 x86_64 unknown

What steps can reproduce the bug?

Simple passthrough from stdin to stdout:

import { Readable, pipeline, PassThrough } from 'node:stream'

pipeline(
    Readable.toWeb(process.stdin),
    new PassThrough(),
    process.stdout,
    () => { },
)

Independently of how you split it with the blocksize:
dd if=/dev/urandom bs=1 count=16383 | bun run <file>.ts > /dev/null: works without any issues
dd if=/dev/urandom bs=1 count=16384 | bun run <file>.ts > /dev/null: writes all the data to stdout, but the process hangs forever intead of stopping when stdin closes

I believe it's stdin read, as the limit is always that, even applying compression to the algorithm.

What is the expected behavior?

Process should exit normally when stdin closes, just like it does with < 16KiB data, node behaves the same.

I noticed tho, that this slight modification seems to prevent the bug:

import { Readable, pipeline, PassThrough } from 'node:stream'

pipeline(
    Bun.stdin.stream(),
    new PassThrough(),
    process.stdout,
    () => { },
)

(TS types are broken tho)

What do you see instead?

The process hangs

Additional information

A side note, isn't the callback function on pipeline supposed to be optional?
At least according to the types, excluding it doesn't cause any issue on my IDE but the code breaks:
TypeError: The "streams[stream.length - 1]" property must be of type function. Received an instance of EventEmitter
Node behaves the same, but the types shouldn't be like that imo... it's nodejs's side anyways.

[javalsai]

Brought up from discord: https://discord.com/channels/876711213126520882/888937948345684008/1199383041601175563 and https://discord.com/channels/876711213126520882/888937948345684008/1200864385837576263

[Jarred-Sumner]

This is fixed in the process PR #8456

[javalsai]

This is fixed in the process PR #8456

It's still happening on 1.0.33, which I think that has that PR included

[jdalton]

When fixed we should remove the 1 line-ish workaround added in: #9580.