fs.openAsBlob reports a missing file as ERR_INVALID_ARG_VALUE, discarding the ENOENT

[gildas-lormeau]

Version

v26.7.0 (reproduced; code path unchanged on main)

Platform

macOS (Darwin 25.5.0, arm64) — not platform-specific

Subsystem

fs

What steps will reproduce the bug?

const { openAsBlob } = require("node:fs");
try {
  openAsBlob("./does-not-exist.txt");
} catch (error) {
  console.log(error.name, error.code, error.message);
  // TypeError ERR_INVALID_ARG_VALUE Unable to open file as blob
}

Always reproduces. Same result for a permission failure — every open/stat failure produces the identical error.

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

A rejection (or at least an error) equivalent to what every other fs open/stat API produces for a missing file: a system error with code: "ENOENT", plus syscall and path. ERR_INVALID_ARG_VALUE (a TypeError) says the argument is malformed, but the path here is a perfectly valid argument — the file just doesn't exist. The docs for openAsBlob don't document any different error contract.

What do you see instead?

TypeError [ERR_INVALID_ARG_VALUE]: Unable to open file as blob — thrown synchronously (the synchronous-throw half is already tracked in #62418), with no errno, syscall, or path. ENOENT, EACCES, and any other underlying failure are indistinguishable.

Additional information

Mechanism:

1. lib/fs.js openAsBlob() calls createBlobFromFilePath(path) synchronously and wraps the result in PromiseResolve.
2. src/node_blob.cc BlobFromFilePath() calls DataQueue::CreateFdEntry(env, args[0]) and, when it gets nullptr, throws THROW_ERR_INVALID_ARG_VALUE(env, "Unable to open file as blob").
3. src/dataqueue/queue.cc FdEntry::Create() returns nullptr for any negative uv_fs_stat/open result, discarding the libuv status code — this is where the ENOENT is lost.

Note that the pending fix for #62418 (PR #62655) only converts the synchronous throw into a promise rejection; its new test asserts code: 'ERR_INVALID_ARG_VALUE' for openAsBlob('does-not-exist'), which would enshrine the misleading code. It would be good to fix the error identity at the same time: have the native side (or FdEntry::Create) propagate the uv status and throw a proper UVException (ENOENT/EACCES/… with syscall/path), as fs.open does.

Real-world impact: the generic ERR_INVALID_ARG_VALUE sent us debugging "path validation" changes for a test-suite failure whose actual cause was simply a cwd-relative path to a file that didn't exist — an ENOENT with the path attached would have made it a ten-second diagnosis.

Related observation while testing (can file separately if preferred): openAsBlob("./some-directory") succeeds and returns a Blob sized to the directory's stat size; reading it later fails with NotReadableError: The blob could not be read. An EISDIR at open time would be more helpful there too.

[bitpshr]

Reproduced on main, and your mechanism walkthrough is exactly right: FdEntry::Create() in src/dataqueue/queue.cc returns nullptr for any negative uv_fs_stat() result, so src/node_blob.cc has nothing left to report but a generic arg error. Opened #65517 to thread the status out and throw a UVException, which gets you ENOENT, syscall: 'stat' and the path, same as fs.stat().

One correction worth recording: the permission case does not behave the way the issue describes. stat only needs traversal permission on the parent directory, so a chmod 000 file opens fine and returns a correctly sized Blob, then fails at read time with NotReadableError (and code: 0). So the failures this actually covers are ENOENT, ENOTDIR, ELOOP and similar, not EACCES.

The directory case reproduces as you describe. There is already a TODO(@jasnell, @flakey5) on FdEntry about restricting it to regular files, so that one is a real behavior change rather than an error-identity fix. I left it out of #65517 to keep the change reviewable, but happy to pick it up separately if that is wanted.

Also flagging the overlap you spotted with #62655: my test is written so it passes whether openAsBlob throws or rejects, but that PR's new test asserts ERR_INVALID_ARG_VALUE and would need a tweak depending on landing order.