fs async functions (both callback and promises APIs) return Errors without stack trace

[ZFail]

• Version: 13.3.0
• Platform: Windows 10 x64

const fs = require('fs')
fs.readFile('nonexistentfile', (err) => console.log(err.stack))

What is the expected output?
The err.stack should contain error text and stack
Same as readFileSync function:

Error: ENOENT: no such file or directory, open 'nonexistentfile'
at Object.openSync (fs.js:446:3)
at Object.readFileSync (fs.js:348:35)
...

What do you see instead?
err.stack only contains error text

Error: ENOENT: no such file or directory, open 'C:\dev\projects\ntest\nonexistentfile'

fs.writeFile have same trouble
Аnother strange thing is that the error text is also different (local/absolute path)

[BridgeAR]

This is sadly a known issue. Tracking the actual call site would be a significant impact for all fs functions and it is therefore not implemented so far. We tried to find solutions but failed so far.

I thought there would already be an issue for this but I failed finding it.

[addaleax]

There’s definitely a number of userland solutions for this issue, though, e.g. https://www.npmjs.com/package/trace.

I wouldn’t mind bringing such an opt-in solution into core.

[BridgeAR]

@addaleax good point, we might just add a flag for that.

[devsnek]

can someone provide a summary of what the technical issue here is?

[BridgeAR]

@devsnek tracking the original call site for the async operation. The only way to really do that is (AFAIK) to create a stack trace for all calls. So it'll reduce the average performance for successful fs calls significantly.

[devsnek]

am i right in saying that the problem is that the error is created in c++ land while the js stack is empty?

[BridgeAR]

I believe we do not even attempt to create a proper error in that case. It would not point to the actual call site.

[addaleax]

@devsnek Yes, that is correct. The exception is created in FSReqAfterScope::Reject.

I’m actually not sure anymore if long stack trace modules solve this. Fixing this might also require us to add better async support for these kinds of operations; the error is currently created outside of the async scope, so no async tracking is available.

One thing that might be helpful for making async stack traces work better here is making FSReqAfterScope create an InternalCallbackScope (and remove the one in FSReqPromise<AliasedBufferT>::Resolve + replace MakeCallbacks with a plain Call()). That way, the error could be created inside the callback scope.

[heroboy]

What about the fs.promises? Is it possible to add full stack traces for fs async functions?
https://v8.dev/blog/fast-async#improved-developer-experience
https://bit.ly/v8-zero-cost-async-stack-traces

[bnoordhuis]

@heroboy If you're talking about the await optimization proposal, that's been implemented in Node.js v12.x and up. You can check if your node binary supports it like this:

$ node --v8-options | grep async.stack.traces
  --async-stack-traces (include async stack traces in Error.stack)

Note that the optimization won't work if your program monkey-patches Promise.

[heroboy]

@bnoordhuis , No. I know current nodejs support this. And I know only async await functions have good support to async stack traces, many Promise functions will lost the stack.So if this issues fixed, will the fs.promises functions have the full stack traces? Will you make effort to make many nodejs' promisify functions to support this?

[bnoordhuis]

There's no need to do anything on Node's side, if I understand your question correctly. It's all done inside V8. The one caveat is that it only works with await and native promises.