Reviving "Zones" like proposals to TC39

[legendecas]

Since original zones proposal had have been withdrawn and its repo has been archived, I've forked another repo on the zones proposal at https://github.com/legendecas/zones and reset to the proper commit. Discuss on this thread is also fine.

The motivation of the proposal can still focus on async contexts in JavaScript, i.e. (1) tracking host tasks scheduled during a period of execution, (2) provided an easy way to inspecting current executing host tasks and its callbacks/promise resolutions, (3) enable toolings that work around the tasks like profiling on the async task run time. Also, common pitfall issues raised in the Node.js domain module, like globally shared instance without isolation between modules, semantically misleading error handling, have to be prevented/addressed in the new proposal too.

@mmarchini mentioned in the last diag meeting that there are a few outstanding proposals that may be overlapping the motivation of the "zones" like proposals. Options can be seeking to promote and work on these proposals too.

[mmarchini]

Reading the proposal again I don't think there's overlap, but we'll need to think about interoperability with other proposals. It seems like the proposal is blocked due to an objection on domenic/zones#9. The thread is huge and I haven't read it yet (will do it in the following days), but without addressing the objections there we can't move forward.

[legendecas]

@mmarchini After reading many threads on the zones proposal, IMO I'd like to keeping the proposal minimal and staying away from error handling at the moment. JavaScript has its own error handling semantics on try...catch, introducing another one the way that Zones do doesn't seem to make the error handling easy to understand.

What's your opinion on what the Zones proposal shall do?

[Qard]

I feel like async/await with try/catch already adequately solves most error handling concerns. The main exception being forgetting to await a promise, but the uncaught exception handler can already deal with that. Might be worth just making a spec to expose the uncaught exception handler somehow. 🤔

[mmarchini]

Might be worth just making a spec to expose the uncaught exception handler somehow

There's some discussion about maybe having this handler as part of the agents proposal.

[mmarchini]

@legendecas are you actively working on the zones proposal (or do you plan to work/have cycles to work in the near future)? I've read the proposal as well as domenic/zones#1 and domenic/zones#9 (the biggest blockers), and I have ideas on how to advance it. If you're too busy right now I can champion it.

After reading many threads on the zones proposal, IMO I'd like to keeping the proposal minimal and staying away from error handling at the moment.

I agree with that, after reading the issues and the domains postmortem, IMO introducing error capturing as part of zones will open the door for misuse of zones as a "catch-all" mechanism, which is far from the goal of the proposal. But note that .wrap(fn) requires a decision on how it will handle errors that happen within fn. IMO it should steer away from always reporting to HostReportErrors, and instead it should retain the current behavior as if fn was not wrapped (meaning if fn wouldn't report to HostReportErrors while not wrapped, it wouldn't while wrapped, same goes to if it would report to HostReportErrors). Since Promise rejections always report to HostPromiseRejectionTracker I think it's less on an issue on the Promise and async/await side.

While I believe error handling and error capturing should not be part of the proposal, I think zones brings an opportunity to improve the concept of async stack traces introduced by V8: instead of limiting async stack traces to async/await, we might be able to expand it across zones. This would be a third proposal though, derived from zones and Error.stack.

[legendecas]

@mmarchini yes, I'm on the process on TC39 delegation as part of TC39 proposal working procedure. Besides that, I've proposed a draft on https://github.com/legendecas/proposal-async-context (this is an early stage draft, ideas are welcome), in which I've listed the error handling as non-goal of the proposal.

While I believe error handling and error capturing should not be part of the proposal, I think zones brings an opportunity to improve the concept of async stack traces introduced by V8: instead of limiting async stack traces to async/await, we might be able to expand it across zones. This would be a third proposal though, derived from zones and Error.stack.

This is cool and may be one of the main motivations for the proposal. I'll update the draft to address this.

Championships are very welcome if you and any person are interested in working on this together.

[legendecas]

@mmarchini and other people may be interested since this topic is quite a large one, I'm proposing a separate online call session to discuss priorities and shape of this early-stage proposal. Anyone interested can fill out this doodle https://doodle.com/poll/r3sxeaevzcm8gtdx, so that we can pick a perfect time for all of us.

[mmarchini]

Thanks for setting this up. I suggest sharing the result here once we have a date so folks don't miss it :)

[legendecas]

So after a few of us have filled the doodle, we have only one timeslot that fit all of us:

Location	Date
Los Angeles	May 12 TUE 9:00 AM - 10:00 AM
New York	May 12 TUE 12:00 PM - 1:00 PM
UTC	May 12 TUE 16:00 PM - 17:00 PM
Hangzhou	May 13 WED 12:00 AM - 1:00 AM

Meeting agenda and notes: https://docs.google.com/document/d/1459W_1uCnrrprTcqpxzw315e4ceVrYJt4xVdJRbxGYk/edit?usp=sharing
Meeting link: https://alimeeting.alibaba-inc.com/alimeeting/web/webvc/alilangpc?uuid=9f3db55a-9061-49c8-877f-e2ae01a13719 (you can join with browsers)

[legendecas]

After we discussed in the meeting, we have the following todos:

• The Cancellation proposal is on stage 1, should be taken in to account.
• Adopt AsyncLocalStorage into the proposal or change the implementation.

The original zones proposal was on stage 0 (tc39/proposals@2764565), so we can rename the new proposal to fit our motivations.

@mhdawson @mmarchini @Qard thank you for your suggestions!

[legendecas]

hey, @benjamingr @bmeck @domenic @trevnorris :D, you have lots of comments and thoughts on original zones proposal repository. So before we are going to present the new async context proposal to TC39 in the very near future, may I have your attention and ideas on this new proposal?

Compared to the Zones proposal, the new proposal is kept minimal and providing a way to track async contexts and async locals. While error handling and task interception are not the priorities and requirements on the proposal after all the features like async/await in JavaScript, I'm wondering if the blocking issue of such an area of proposal is cleared from your point of view.

[domenic]

I am no longer involved in TC39. But from my perspective any proposal which doesn't have error handling affordances (notably the two ways to wrap/propagate contexts) is not likely to succeed, and would be bad for the ecosystem if it did.

[mmarchini]

After reading all the discussions in the original zones repository, I have an opposing opinion: a proposal with error handling is unlikely to succeed, because it mixes error handling and mapping asynchronous continuity (two different concepts). A separate proposal for "error capturing context", which is not limited to async contexts (but take those into account) might be more appropriate.