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
Async functions are downleveled to a generator, using the __awaiter wrapper.
If an async function throws an exception, the stack trace includes the call to __awaiter and then the internals of __awaiter in the following frames. The problem is with how to map those to source code.
Using importHelpers and noEmitHelpers helps with producing stable stack frames for the __awaiter internals, that can be mapped back to tslib.
However, the very call to __awaiter in my app code is still inlined, and it currently doesn't have any mapping.
This makes it a problem with tools that rely on stable stack traces. Logging tools, such as Sentry, heavily use mapped stack traces to group multiple occurrences of the same error into a single bucket. Inability to map some frames prevents such grouping, which results in all sorts of problems when monitoring the app in production (false alarms, noise on the dashboard).
Similar issues about async sourcemaps - which I still believe describe different problems than mine:
Here I enabled source maps. If you decode it, you can see that there is no mapping for line (2) (the __awaiter(this, void 0, void 0, function* () call). Yet, this line is present in the stack trace.
// compiled.jsfunctioncallAsync(){return__awaiter(this,void0,void0,function*(){// <----- This line (2) is present in error stack tracethrownewError('sync');});}callAsync();
🙁 Actual behavior
Stack trace includes line (2) (the one with the awaiter call). However, the sourcemap doesn't have a mapping for this line
🙂 Expected behavior
I don't know, frankly. Why don't we map this line to the declaration of our async function (source line 1)? Or to the declaration of the awaiter helper?
The text was updated successfully, but these errors were encountered:
Bug Report
Async
functions are downleveled to a generator, using the__awaiter
wrapper.If an async function throws an exception, the stack trace includes the call to
__awaiter
and then the internals of__awaiter
in the following frames. The problem is with how to map those to source code.Using
importHelpers
andnoEmitHelpers
helps with producing stable stack frames for the__awaiter
internals, that can be mapped back totslib
.However, the very call to
__awaiter
in my app code is still inlined, and it currently doesn't have any mapping.This makes it a problem with tools that rely on stable stack traces. Logging tools, such as Sentry, heavily use mapped stack traces to group multiple occurrences of the same error into a single bucket. Inability to map some frames prevents such grouping, which results in all sorts of problems when monitoring the app in production (false alarms, noise on the dashboard).
Similar issues about async sourcemaps - which I still believe describe different problems than mine:
🔎 Search Terms
sourcemap, async, awaiter, generator
🕗 Version & Regression Information
I tested it in 3.5, 4.2 and 4.3. Probably it has always been the case.
⏯ Playground Link
Playground link with relevant code
Here I enabled source maps. If you decode it, you can see that there is no mapping for line (2) (the
__awaiter(this, void 0, void 0, function* ()
call). Yet, this line is present in the stack trace.💻 Code
🙁 Actual behavior
Stack trace includes line (2) (the one with the awaiter call). However, the sourcemap doesn't have a mapping for this line
🙂 Expected behavior
I don't know, frankly. Why don't we map this line to the declaration of our async function (source line 1)? Or to the declaration of the awaiter helper?
The text was updated successfully, but these errors were encountered: