`openAsBlob` fails synchronously

[remcohaszing]

Version

v24.14.0

Platform

Linux vali 6.18.7-76061807-generic #202601231045~1769703228~24.04~cb87b5b SMP PREEMPT_DYNAMIC Thu J x86_64 x86_64 x86_64 GNU/Linux

Subsystem

fs

What steps will reproduce the bug?

import { openAsBlob } from 'node:fs'

const result = await openAsBlob('does-not-exist').catch((error) => {})

console.log(result)

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

Always

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

I expect openAsBlob() to always return a promise. If there are any problems, I expect the promise to be rejected.

What do you see instead?

Instead of returning a promise that’s rejected, openAsBlob() fails synchronously. This means that instead of using the Promise.catch() method, you have to use try/catch logic instead.

Additional information

Just marking the function as async on https://github.com/nodejs/node/blob/v25.8.1/lib/fs.js#L570 would fix it.

[targos]

@nodejs/fs

It's a weird one. I've also always wondered why the function is on node:fs instead of node:fs/promises.

[remcohaszing]

I understand if new, modern APIs use a promise approach instead of a callback, even if they are exported from node:fs. But I have to admit I was a bit puzzled at first when I couldn’t import openAsBlob from node:fs/promises.

[Xstoudi]

Maybe it's worth mentioning #49759 as previous work on node:fs vs node:fs/promises.

The solution mentioned in additional info works. That said, moving Promise-based implementation to node:fs/promises and having a callback-based implementation in node:fs would fix the oddity of finding a Promise-based implem among callback-based functions. Not sure if it's really desirable to have a callback-based implem tho.

[mattskel]

@remcohaszing This change makes openAsBlob reliably return a Promise in all cases by converting any synchronous validation or creation errors into Promise rejections. That matches the Promise-based contract discussed in the issue, so callers can always use await/.catch without missing sync throws.

@Xstoudi Similar to #49759 to handle errors. But instead retains the promise based contract.

I’ve opened this as a draft PR to get early feedback. If reviewers agree with the approach, I’ll follow up with tests.

[damianremington274-blip]

Thank you for opening the draft PR for this. Converting the synchronous errors into Promise rejections makes sense and aligns with the expected Promise-based contract for openAsBlob. It should definitely make the behavior more predictable for callers using await or .catch.

…

On Thu, Apr 9, 2026, 11:50 AM mattskel ***@***.***> wrote: *mattskel* left a comment (nodejs/node#62418) <#62418 (comment)> @remcohaszing <https://github.com/remcohaszing> This change makes openAsBlob reliably return a Promise in all cases by converting any synchronous validation or creation errors into Promise rejections. That matches the Promise-based contract discussed in the issue, so callers can always use await/.catch without missing sync throws. @Xstoudi <https://github.com/Xstoudi> Similar to #49759 <#49759> to handle errors. But instead retains the promise based contract. I’ve opened this as a draft PR to get early feedback. If reviewers agree with the approach, I’ll follow up with tests. — Reply to this email directly, view it on GitHub <#62418 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7YAFGT3DXWDP6M7MUWHC5T4U7IF5AVCNFSM6AAAAACW5ORS52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMJVHE3TGNRZGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[github-actions]

This issue has been marked as stale due to 90 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.

[remcohaszing]

This issue isn’t stale. There’s an open PR. If that PR gets rejected, I would like to open a new one myself using the solution I proposed in this issue description.

[jimmywarting]

It's a weird one. I've also always wondered why the function is on node:fs instead of node:fs/promises.

I agree. It has come up again and again in different threads that:

• openAsBlobSync should exist on node:fs
• openAsBlob should be copied over to node:fs/promises
• It's weird that node:fs#openAsBlob doesn't have a callback form. It could theoretically support an optional callback form as well, which would fix this quirk.
• The lack of getting files as a File class is also a #developerPain for some.

A desired api:

const blob = fs.openAsBlobSync(path, { type })

const blob = await fs.promises.openAsBlob(path, { type })

// For backwards compatibility, always return a promise.
const blob = await fs.openAsBlob(path, { type })

// The old one could also support an optional callback function.
fs.openAsBlob(path, { type }, (err, blob) ={
  // ...
})

// Getting things as a `File` class would also give us the base file name
// and the last modified date.
const file = fs.openAsFileSync(path, { type, lastModified, name })

const file = await fs.promises.openAsFile(path, { type, lastModified, name })

fs.openAsFile(path, { type, lastModified, name }, (err, file) ={
  // ...
})

To get a file with a name and lastModified date, you currently have to stat it yourself:

const name = path.basename(filePath)
const stat = fs.statSync(filePath)
const blob = await fs.openAsBlob(filePath)
const file = new File([blob], name, {
  type: blob.type,
  lastModified: Number(stat.mtime)
})

The lack of a synchronous operation forces developers who want a File class instead of a Blob to make their code asynchronous as well, simply because there is no way to retrieve the Blob synchronously.