Node.js Technical Steering Committee, 26 Feb 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Node.js Technical Steering Committee meeting - Feb 26 2020

Description

https://github.com/nodejs/bootstrap/issues/114

A

Welcome to the no jest technical steering committee meeting for 426 2020 organ follow the agenda which was supposed to in the issue within the TSE supposed.

B

A

27 we have fairfield later, but we'll start with somebody have any announcements that they like share. I.

A

Think nobody has any others. I can share that. The abyss world has been expense wise to think to the end of this week, and the registration is also open for the open to girls as well. Also getting.

C

Very different.

A

Okay, am I back yes.

D

Loud and clear, okay.

A

Okay, so we were just moving on to the agenda unless there was some other discussion going while I was off.

A

No okay, so the first thing tagged. Oh sorry, I was looking at the board for the updates on the board. So this week is the board meeting. So if there's anything that hasn't been brought up already, just let me know so that I know to bring it in terms of the first thing on the board. Our request to the board for build resources. I can't remember the last.

A

The latest update I gave on that, but recently we got another a couple: people from Microsoft who are involved in the electron team who've been identified as having between the two of them a day a week to help contribute on the build side.

A

So we now have a new person from Google and a couple more people from Microsoft we're gonna get involved, and you know working on getting them connected and ramped up on the build working group, so I think we're making some progress there and we'll see you know how much getting those people on boards or it sort of helps to lessen some of our existing issues and, on the other request, we're gonna have a private section at the.

B

End will change.

A

So we'll cover that sorry, what was that Gabriel.

B

Please promote James, ah promote.

A

James, okay, thanks, okay, so I think that's the update on the board, as I said any questions or things that we want to discuss on that front before we move on.

A

Now, okay, so let's move on to the first issue, which is tagged in the agenda: it is number 31 317. Our recent behavior change of buffered write, callbacks I'm, just gonna. Look to see who opened that tag that yeah. It was me okay, so Matteo when you take that one.

E

So yeah they brought the. What happened is that we made a change back last summer on how callbacks are handled in streams, and what happened is that we change it. We made the callbacks always be cold before that the callback could could be not cold in Kate's, a stream Herald. So if you do dot right and you pass a callback to write stream that right and you pass a callback to write that called in 12 and before that, that call bet main was in some cases, was not cold at all, resulting in possible.

E

You know, memory, leaks and other problems in 13 in 15. Last summer we landed a change from renege that was making those callbacks always cold inking, the stream was destroyed or, and we destroyed, which meant that those colbus was called with an error. Note that these was is actually some of those might. This is less.

E

It's not to some extent perfect in the sense of you know, it was not really finished with an error. They just really never happened because the stream was closed, so that was that the crux of the issue. The reason why we're bringing this up at the THC level is because Luigi Pinker would have objected to that change at that point because it doesn't, it doesn't agree with it essentially, and he would like to have some opinion on how to proceed.

E

Essentially in case you deeper show our super pusher pusher I revert or we should not.

E

You should not do something like it. You should keep things Laz, it is for Luigi, not all callbacks must be called and a lot of code I am reading from the issue are only called the responsible, specific event operation. So if the operation never occurred is the callback should not be called for him and.

E

You and that there have been some side effect for these happening in some PR, so that are currently blocked. I.

B

Have a question so my understanding of this is that- and this is just just for me- to clarify it in my own head. So basically, but what used to happen was a stream would would be called every everywhere. I'd come back would be called until there was an error, in which case one of the last one to be called little Dan error and then it'd been silent. Is that how the behavior was no.

E

It's if the stream was cold. So if there was a bunch of.

E

Right calls that we're so, let's say only one right: callbacks only what one bright up and at a time, even if you could write multiple times so if you have multiple flights being done in parallel with the callback hits, what happened was that when you did, the stream was destroyed from the other side, for example, it was what we'll have. What is what will have happened is that those coal beds will never be cold.

E

Not even with an error, not even with an error exactly my PAPR that we pushed through was make actually make them called with an error.

B

So, okay, my only my only point of view here is and I don't have a lot of experience with streams. I just are just looking at this conceptually right. We have to consider the stream if you consider the stream to be an object right. That's it stateful right, and so so. If there is an error that affects the entire stream and not just individual rights, then then that error should be presented at least once per stream, rather than provide.

E

Presented by two at the stream level on the UH narrow event, the difference is sure the individual callbacks be cold or not, even though that individual callback never error, because the streams finished an error from the other side.

B

Okay, so okay, but but even before this change, there was a clear indication that the stream had error. So technically, you could argue that the that whoever is using this API should basically keep a keep in mind which callbacks were not called and then and then basically upon error, do any and all necessary clean.

B

You could argue that, but then button we are not providing a lot of value, because now they also have to do buffering of the callbacks right yeah.

E

So, essentially this because the unit can never know if a callback was told or not, then, for example, if you wrap them in a promise, you will not know if that promise was never a solver reject.

E

So you need to track essentially what happened in all of them. If you want to rely on that behavior with this change, you can actually avoid that.

F

What widest letters okay come on? It reverted like what who does this break? It sounds like again overwhelmingly good idea to call your callbacks eventually yeah.

E

That is my part. That is my point view. So I am representing the issue because Luigi as.

E

Luigi is pretty is asking for an opinion from the TSC. If you should poor shall revert or not. This is so. What.

D

Is our orientation if.

E

You put through a revert, and now we would be like you know, is asking for guidance. Ascension.

F

I-I-I, I'm back to the question of like who does it break yeah? What's the case for reversing it, he must have a reason for wanting to revert it.

E

Word for it, it's.

E

E

The case forever thing is that it's, the behavior, is significantly different and is not easy to monkey patch, and so supporting multiple versions of the GS becomes way harder and essentially makes them very unreliable.

E

So that is probably the biggest effect.

F

Cause like I'm pipeline and pipe were fine with either behavior like are.

E

You fine because they are relying on the outer.

E

We are fine with because they are relying on the outer error handler.

E

There are also been some side effects on on this. Essentially, you know.

A

What do you mean by that.

E

So if you read through the issue, they said there have been some side effects and some box being open.

B

Please promote rich sure.

E

So there are two I would recommend for you to look to the issue. There's a lot of context and a lot of like lot a lot of tests, so I'm just trying to sum it up right now,.

B

It also sounds like it might be good on a call like we invited him this time, but he couldn't make it hopefully I.

E

You know I'm actually trying to I would recommend for you to go to the issue and I can. Potentially, we can potentially call for a vote next time or counter number substantially. I am I.

E

Lgt am the original change in.

E

Ihdt I am the original change. Other people that lgt am the original change, was.

E

Richard rich trot and Anna.

C

C

Don't know why did I.

A

Did try to see if we could make next week as well, and he said he can't I.

G

E

You know I I, don't from my point of view, it seems I, don't know what, if anybody that go to the issue thinks that this is this a good idea and we should revert. I am I'm personally not of that opinion, but we have been asked to get him to get Luigi a formal answer. So I am of the opinion of that. The call back should be called all the time. That is my opinion. So.

B

The question possible: is it possible in a stream that that an individual right will fail, but that does not necessarily mean that the entire Stream is now useless right. So the next right, my.

E

Everytime, the stream is every time if he covers its users.

B

Ost, okay, okay, so so, okay, alright! So there's no possibility of recovery with the next right know.

A

Which releases is at least likely to go to disco out in 13.

C

D

Open to the idea that we should find a way to make backwards, compatible support easier, but I, don't I'm reluctant to revert I.

G

Agree: I'm gonna, reluctantly to revert the new behavior is I, think better.

G

Rather avoid breakage. If we get through some some ways, we can work around it, but I don't I, don't that forward as well.

F

Just to be clear was the old behavior that definitively one call back would call back with air and then no more, where callbacks would occur after that exactly, but there would definitely be one of the outstanding rights that would get an error. Yes, well.

H

The beef- yes, yes, I, never.

F

Never more than one or just like.

E

F

E

The only the one if there was one that was going to being breached if it was called zero if the stream was corked vo. If.

F

Somebody did a read in the read aired: that's freakin stream yeah in that case with.

H

Her the way read works. It's.

E

It will only that does not have a callback, so that would that we don't have this problem. The three-man we get toyed with in on error event under so.

F

Right, but if you, if you had a stream it had some rights open, you did a read something we didn't have a call back. The read did an underlying call which aired and the stream gets destroyed. Yeah. Would the outstanding rates get a call back? No, no were there just being aware of and saying hey we're done here.

E

This is a very hard question that I would need to get through and some examples to give you a definitive, definite 'iv answer. He really depends on the underlying implementation. From my point of view, so.

E

In case of net- probably yes, it would have a turd in the generic case. I, don't think so.

F

I yeah I, see, there's I, think there's a a general problem in the streams and that there's kind of three flows of events there's destroy events which sit in their own universe. There's the read stream in the right stream and the the causal relationship between those three semi-independent things, particularly on actors. It isn't really well-defined. Oh it totally.

H

F

It is it's better, the this rule where, if you I think, if you do an operation yeah and you gave it a callback, your callback will get out. Yes, yeah I think that's a better.

E

That's my hint as a genetic topic I think that so that would be my recommendation person, but I would be happy to if somebody has a different opinion. Yes, please engage also engage in the PR. If you would like to.

E

To tell overall, you got core quorum, Michael.

A

We of 13 people here Brian, which is 12, so we have more than a policy. Okay.

E

So does anybody object me getting back telling that overall we like do, we would like to have callbacks being cold all the time.

E

Is these I would.

I

Not have any objections: one-plus yeah, no.

E

Objection, the yeah okay, I, would also put it into the into the case in this case, I would put it in generic I'll put it generally, but it needs to evaluate at case-by-case and I would. If we can make this a little bit better than backward-compatible.

E

A

And I would cast it. As you know, twelve twelve of the TSE members who were there didn't have any objections. We didn't necessarily have a vote or anything right so yeah exactly but yeah. But if you're asking for an opinion, that's you know.

E

That's what that the opinion there is nobody objecting off on this right of this line. Okay, so if we didn't dwell that's you know, that is.

A

Because it's always possible the other people might have a different opinion, but I.

E

A

It's valid to go back and say from the people there. This is good.

E

Number so, okay, you know I was just checking because if you were under quorum it would have been way less.

E

Meaningful essentially, we know that we have a significant amount of people that are not objecting and please engage in the PR Sam or anybody that wants to know more. It's it's actually some important changes in behavior, so it's actually some long-standing bucks. I personally had to dig deep into the stream subject, one more than then was to actually call that call back because it was not being called so there is that.

E

Okay, I think you're good to go so thank.

A

You okay, so that was our first issue. The next issue, actually I think we talked about last week and I haven't had time to put any more or work into it in terms of coming up with an agenda for node.js future directions summit, either online or at the next summit. So unless anybody wants to add something to that, I suspect I suggest we move on.

A

No at that point, we are at the end of the issues that were tagged for the agenda. Are there any other issues that people want to discuss before we move on to the private section?

A

A

Okay, if not I'm, going to stop the livestream, so thanks to everybody, who's been watching and we'll see you next week.