Enrich stack traces with an API to add notes to a current stack frame

[jaredp]

Is your feature request related to a problem? Please describe.
Stack traces are a key debugging feature, but miss critical information in frame local variables. Imagine code like

async function fetchAllUrls() {
  for(const url of ["https://provider-one.example.com", "https://provider-two.example.com", "https://provider-three.example.com"]) {
    await parse(await fetch(url));
  }
}

that fails with stack trace

Error: invalid schema
    at parse (/workspace/test.js:3:14)
    at fetchAllUrls (/workspace/test.js:14:31)
    ...

it would be critical know that https://provider-two.example.com/ is broken, and not one or three. It's especially important if the failure is transient.

Describe the solution you'd like

 async function fetchAllUrls() {
   for(const url of ["https://provider-one.example.com", "https://provider-two.example.com", "https://provider-three.example.com"]) {
+    Context.addDebuggingContext(`url=${url}`);
     await parse(await fetch(url));
   }
 }

gives stack trace

Error: invalid schema
    at parse (/workspace/test.js:3:14)
    at fetchAllUrls (/workspace/test.js:14:31) [url=https://provider-two.example.com]
    ...

Describe alternatives you've considered
I currently pass an explicit Context object down the call stack from caller to callee, accumulating debugging info. When my code throws, it includes a pretty-print of the Context in the error message. This doesn't work with errors thrown by 3rd party code (npm, node builtins/internals).

We can also wrap callees with a try...catch and rethrow errors with extra annotation. There's no nice way to do this with error objects, and the try...catch is believed to have a perf impact.

[mhdawson]

@nodejs/diagnostics FYI

[BridgeAR]

@jaredp IMO the ideal way is to wrap third party libraries in try / catch and to create an own error that uses the cause part with the original error. You are able to add what ever information you want in that case as extra properties.

It is possible to keep the overhead to an absolute minimum by setting Error.stackTraceLimit to zero before creating the new error and to reset it to the former value after that. That way you'll still have the original stack trace but do not have to create a new stack trace that is not needed.

[cjihrig]

I currently pass an explicit Context object down the call stack from caller to callee, accumulating debugging info.

You might be able to leverage Node's async context tracking to avoid passing a context object everywhere.

I'd also take a look at https://v8.dev/docs/stack-trace-api (just note this API is V8 specific).

[tniessen]

We can also wrap callees with a try...catch and rethrow errors with extra annotation. There's no nice way to do this with error objects

IMO the ideal way is to wrap third party libraries in try / catch and to create an own error that uses the cause part with the original error. You are able to add what ever information you want in that case as extra properties.

FYI, @BridgeAR is referring to https://github.com/tc39/proposal-error-cause, which addresses this use case to some degree.

I think it would be difficult for Node.js to modify stack traces beyond what JS / V8 already offer.

[mmarchini]

That's the kind of use case where llnode thrives. Unfortunately, it's not a user friendly tool and it doesn't currently work on v14+. I also worked on a proposal for inspector protocol-based postmortem tooling in the past, but it had a huge overhead.

FWIW I'm definitely +1 on an API that allows functions to enrich their contexts on stack traces, but for it to be performant and stable it would need to be worked with V8 and probably with TC39 too. Having been part of these discussions in the past I don't have much hope for it, but I'd endorse anyone trying to move the needle in this space.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.