Discuss blocking on Zones proposal

[bmeck]

https://github.com/domenic/zones is a proposal that is currently being blocked by Node.

The proposal is something similar to domains and async_hooks in creating a way to pass data through asynchronous tasks.

The blocker has been the handling of errors with the proposal.

I would like to setup a meeting to discuss the blocking behavior now that async_hooks is landed.

[jasnell]

Count me in.

[mcollina]

@bmeck can you link the original discussion? Which were the arguments that blocked it?

[bmeck]

@mcollina most of the discussion is in domenic/zones#9 . That was the addition of error handling.

Most of the concerns were with the similarity w/ domains and the problems from those. See the domain post-mortem and polyfill using domains.

Over the last year opinions of supporting async workflows w/ error handling like Promises and tooling around swallowed errors has been improved greatly. I think we should re-iterate on the discussion from scratch.

[Fishrock123]

I guess I can join - can we experiment with something that achieves the goal of zones without necessarily using it's current proposed API?

I mean with the API may be fine to but only if VMs can entirely optimize the -every API call passes through it- overhead away.

[benjamingr]

I would love to attend a meeting about it since I have a lot of experience with the problem

[bmeck]

@Fishrock123 we have some flex on the API, but not on removing error handling as per domenic/zones#10 (comment)

[jasnell]

can we experiment with something that achieves the goal of zones without necessarily using it's current proposed API?

Let's not use this thread to begin litigating on the specifics of the proposal, that's not going to be a good use of our time now. Setting up a call to begin that process is the right thing.

[benjamingr]

I've just reread it. @trevnorris has shown in the domains postmortem why they broke (of "mine" "their" "mine" with the middle not cleaning). He then showed with @bmeck why it doesn't work with Zones like it didn't with domains.

It's amazing that Node can block this - and we did the right call doing so. It's a shame because without the error handling it was very nice for many other things as well.

[bmeck]

@benjamingr I agree (hence my previous involvement), but a meeting can make a discrete list of what Node is blocking for error handling would be good. There is a consistent desire for "thread" context, but we can't move it forward without the error handling use case. A meeting on what is different about error handling now that tooling has evolved and what async_hooks allows seems prudent since this proposal is potentially being withdrawn if we don't move anywhere on it.

[Fishrock123]

assigning in a meager attempt to not forget about this

[Trott]

I'm going to close this, but feel free to open another issue in a relevant active repository (TSC perhaps?) and include a link back to this issue if this is a subject that should receive continued attention. Recent governance changes mean this repo probably shouldn't be used anymore. Sorry for the inconvenience.