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
I finally understand this warning about using the ZoneContextManager for OTEL tracing in the browser:
Please note that due to an issue with zone.js, the ZoneContextManager does not work with JS code targeting ES2017+. In order to use the ZoneContextManager, please transpile back to ES2015.
And I'm pretty sure it explains this issue that @rmunn was having:
But the async refine call didn't produce a validation error when it returned false
When I returned Promise.fulfill(false) from a sync refine call, it produced a validation error
But when I returned fetch('/api/...').then(return false), i.e. a Promise that isn't already fulfilled, no validation error showed up in the form
I don't think we're currently having any "real" issues, like this one. We don't use afterNavigate, but there could be other affected hooks etc.
Essentially, ZoneContextManager (or zone.js more specifically) doesn't support native Promises or async/await syntax (because that syntax using native Promises). So, its tracking of asynchronous operations gets buggy in those scenarios. And then I guess weird things can happen.
Here's the issue tracking zone.js' support of async/await syntax. Essentially it sounds like it will never happen.
Our options:
Leave things the way they are:
➕ we benefit from ZoneContextManager handling the async APIs that it can track/instrument
➖ weird bugs could arise
Try to transpile back to ES2015 out async/await syntax using babel-plugin-transform-async-to-promises. Which is apparently how Angular solves it
➕ ZoneContextManager would be happy and we might even get better traces (e.g. thismight actually end up in the context of a trace)
➖ It's trickier to do this with Svelte than with other non-compiler based frameworks
➖ Transpiled code results in uglier/less readable stack traces
Drop ZoneContextManager
➕ The risk is gone
➖ Some of our traces might fall apart
The text was updated successfully, but these errors were encountered:
I updated the description. It sounds very likely that zone.js will never be able to support async/await and people are transpiling (only) that syntax out. The most promising alternative on the horizon seems to be an 8 year old language proposal that probably won't make it into ES any time soon 😆.
Wow, interesting stuff. Having read about the problem more, I can see how zone.js will never be able to support async/await. In ES proposal land, I suppose that 8 years is not horrible, or is it?
Interesting problem. Dotnet actually had this problem and solved it with AsyncLocal which sounds like the async contexts is their version of that. It sounds like it would be worth checking out droping ZoneContextManager and see how that works for us. Maybe it won't but It's not clear what the tradeoffs are right now.
I finally understand this warning about using the
ZoneContextManager
for OTEL tracing in the browser:And I'm pretty sure it explains this issue that @rmunn was having:
I don't think we're currently having any "real" issues, like this one. We don't use
afterNavigate
, but there could be other affected hooks etc.Essentially,
ZoneContextManager
(or zone.js more specifically) doesn't support native Promises orasync
/await
syntax (because that syntax using native Promises). So, its tracking of asynchronous operations gets buggy in those scenarios. And then I guess weird things can happen.Here's the issue tracking zone.js' support of
async
/await
syntax. Essentially it sounds like it will never happen.Our options:
➕ we benefit from
ZoneContextManager
handling the async APIs that it can track/instrument➖ weird bugs could arise
back to ES2015outasync
/await
syntax using babel-plugin-transform-async-to-promises. Which is apparently how Angular solves it➕
ZoneContextManager
would be happy and we might even get better traces (e.g. this might actually end up in the context of a trace)➖ It's trickier to do this with Svelte than with other non-compiler based frameworks
➖ Transpiled code results in uglier/less readable stack traces
ZoneContextManager
➕ The risk is gone
➖ Some of our traces might fall apart
The text was updated successfully, but these errors were encountered: