You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a coupleplaces in JSThreadSafeFunction that call JSError.Fatal(ex.Message), where the exception message alone might not be enough information to diagnose the error.
As an example, a particular AOT trimming problem resulted in an error:
FATAL ERROR: DefaultCallJS at D:\a\1\s\src\NodeApi\Interop\JSThreadSafeFunction.cs:303
Constructor on type 'Microsoft.Extensions.Http.Resilience.Routing.Internal.RequestRoutingOptions' not found.
The full stack trace revealed that type instantiation was attempted by Activator.CreateInstance() which clearly indicates a trimming issue because the trimmer does not detect such dynamic instantiations.
Either the fatal error message should include the exception stack trace, or we should find a way to propagate the exception as a non-fatal JS error, where the .NET stack will be merged with the JS stack.
The text was updated successfully, but these errors were encountered:
or we should find a way to propagate the exception as a non-fatal JS error, where the .NET stack will be merged with the JS stack.
The reason this didn't work is because the .NET method was async void. After changing the method to async Task and awaiting it from JS, I got the full combined .NET + JS stack trace.
Still I guess it would be helpful to print the full .NET stack trace along with the fatal error message. Possibly with a note to the effect of "don't use async void".
This sounds like something that would have been caught by VSTHRD100 - should this project recommend downstream projects to use the VS threading analyzers?
I don't think the VS threading analyzers are particularly more important here than anywhere else.
I looked into this more, and there is still a bug here in how the async void exception is handled. Rather than causing an immediate fatal error, it should be passed to Node.js which treats it as an unobserved promise error. I have some pending changes that accomplish that. With those changes then I get this message:
(node:37500) [DEP0168] DeprecationWarning: Uncaught N-API callback exception detected, please run node with option --force-node-api-uncaught-exceptions-policy=true to handle those exceptions properly.
Then if I do run with node --force-node-api-uncaught-exceptions-policy=true, I see the exception message and stack trace. Since this is a deprecation warning, presumably that will be the default behavior in some future version of Node.js.
There are a couple places in
JSThreadSafeFunction
that callJSError.Fatal(ex.Message)
, where the exception message alone might not be enough information to diagnose the error.As an example, a particular AOT trimming problem resulted in an error:
The full stack trace revealed that type instantiation was attempted by
Activator.CreateInstance()
which clearly indicates a trimming issue because the trimmer does not detect such dynamic instantiations.Either the fatal error message should include the exception stack trace, or we should find a way to propagate the exception as a non-fatal JS error, where the .NET stack will be merged with the JS stack.
The text was updated successfully, but these errors were encountered: