Bug in fileHandle.readableWebStream implementation

[pdaehne]

Version

v24.2.0

Platform

Darwin mac.igd.fraunhofer.de 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:25 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6020 arm64

Subsystem

No response

What steps will reproduce the bug?

Start the attached script.

bug.zip

#!/usr/bin/env node

import * as fsPromises from 'node:fs/promises';

const scriptURL = new URL(import.meta.url);
const fileHandle = await fsPromises.open(scriptURL);
const readableStream = fileHandle.readableWebStream();
const reader = readableStream.getReader({ mode: "byob" });
const arrayBuffer = new ArrayBuffer(3);
const view = new Uint8Array(arrayBuffer, 2, 1);
const result = await reader.read(view);

How often does it reproduce? Is there a required condition?

Always.

What is the expected behavior? Why is that the expected behavior?

I do not expect to get an exception.

What do you see instead?

I do get the following exception:

node:internal/fs/promises:689
  validateOffsetLengthRead(offset, length, buffer.byteLength);
  ^

RangeError [ERR_OUT_OF_RANGE]: The value of "length" is out of range. It must be <= -1. Received 1
    at read (node:internal/fs/promises:689:3)
    at fsCall (node:internal/fs/promises:467:18)
    at FileHandle.read (node:internal/fs/promises:199:12)
    at Object.pull (node:internal/fs/promises:322:37)
    at invokePromiseCallback (node:internal/webstreams/util:172:10)
    at Object.<anonymous> (node:internal/webstreams/util:177:23)
    at readableByteStreamControllerCallPullIfNeeded (node:internal/webstreams/readablestream:3145:24)
    at node:internal/webstreams/readablestream:3295:7 {
  code: 'ERR_OUT_OF_RANGE'
}

Node.js v24.2.0

Additional information

There seems to be a bug in line 321 of "node/lib/internal/fs/promises.js". The line currently looks like this:

const { bytesRead } = await readFn(view, view.byteOffset, view.byteLength);

It probably should look like this:

const { bytesRead } = await readFn(view, 0, view.byteLength);

You want to read to offset 0 of the Uint8Array "view", not to the byteOffset of its underlying ArrayBuffer.

I'm not able to test this fix (I cannot build node.js myself).

[juanarbol]

Are you going to fix it?

[mertcanaltin]

@pdaehne hello would you like to open Pr for this place:

In BYOB reader, the view with offset already comes, and
is automatically offset.

Return only the base pointer from Buffer::Data() and let the
view handle its own offset:

char* Data(Local<Value> val) {
 CHECK(val->IsArrayBufferView());
 Local<ArrayBufferView> ui = val.As<ArrayBufferView>();
 return static_cast<char*>(ui->Buffer()->Data()); // only base pointer
 }

[pdaehne]

I do not understand what you want me to do, please clarify.

As I already wrote above, in my opinion the bug is located in line 321 of "node/lib/internal/fs/promises.js". I did fix this in my local fork of node, added a test, and the test passes:

https://github.com/pdaehne/node/commit/f6dfeb4a1eca98344e7e99e5862d9b6fa310abbc

I'm perfectly ok with creating a pull request with that fix.

I also tried your change in line 253 of "node/src/node_buffer.cc". It does not fix my problem, and it does not pass the test.

https://github.com/pdaehne/node/commit/6b9d3ef8c13de1a6b8cdc7e9b3457e05ac24e4b0

Obviously I will not create a pull request with a fix that does not work.

[mertcanaltin]

Yes, you are right, I thought wrong for a moment, I thought that this problem was in return ByteOffset and that we should not solve it on the cpp side, but what you said seems healthy to me.

[pdaehne]

Ok, I did create a PR for my fix.

[github-actions]

This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[github-actions]

This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.