New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

domain: support promises #12489

Closed
wants to merge 10 commits into
from

Conversation

@addaleax
Member

addaleax commented Apr 18, 2017

Not entirely convinced this should happen, but @misterdjules brought it up and I thought one might as well give it a try. ¯\_(ツ)_/¯ Take a look, and let me know what you think.

Aside: It seems like a V8 design bug that Isolate::SetPromiseHook()/PromiseHook() don’t take a void* data opaque, does anybody agree? I’d probably like to change that in V8 then. (Also, same question for Isolate::SetPromiseRejectCallback()… am I missing something? This can’t be intentional, right?)

/cc @nodejs/diagnostics and fyi @ORESoftware

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included (somewhat? I guess?)
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

domain

@benjamingr

I'm not sure this should happen either - but it solves a problem for a few users.

Also pinging @caitp @littledan about the promise hooks so they can take a look.

@jasnell

Not entirely convinced on this either but the change generally looks ok.

Show outdated Hide outdated src/node.cc
if (enter_v.As<Function>()->Call(context, domain, 0, nullptr)
.IsEmpty()) {
FatalError("node::PromiseHook",
"domain enter callback threw, please report this");

This comment has been minimized.

@jasnell

jasnell Apr 18, 2017

Member

report to whom? If this would be considered a Node.js core bug, then the error message should be more descriptive.

@jasnell

jasnell Apr 18, 2017

Member

report to whom? If this would be considered a Node.js core bug, then the error message should be more descriptive.

This comment has been minimized.

@addaleax

addaleax Apr 18, 2017

Member

This is copied verbatim from MakeCallback ¯\_(ツ)_/¯ I’ve updated this to be a bit more descriptive anyway.

@addaleax

addaleax Apr 18, 2017

Member

This is copied verbatim from MakeCallback ¯\_(ツ)_/¯ I’ve updated this to be a bit more descriptive anyway.

This comment has been minimized.

@jasnell

jasnell Apr 18, 2017

Member

I thought it looked familiar :-) We should likely fix it over there also :-)

@jasnell

jasnell Apr 18, 2017

Member

I thought it looked familiar :-) We should likely fix it over there also :-)

This comment has been minimized.

@addaleax

addaleax Apr 18, 2017

Member

Probably, but I’m not eager to touch that code until #11883 lands. After that I’d be up for all kinds of refactoring… aside, I don’t think there has been a bug report for this crash site in forever, so it probably doesn’t really matter. :)

@addaleax

addaleax Apr 18, 2017

Member

Probably, but I’m not eager to touch that code until #11883 lands. After that I’d be up for all kinds of refactoring… aside, I don’t think there has been a bug report for this crash site in forever, so it probably doesn’t really matter. :)

Show outdated Hide outdated src/node.cc
domain->Get(context, env->exit_string()).ToLocalChecked();
if (exit_v->IsFunction()) {
if (exit_v.As<Function>()->Call(context, domain, 0, nullptr)
.IsEmpty()) {

This comment has been minimized.

@jasnell

jasnell Apr 18, 2017

Member

Minor nit, feel free to ignore but the indenting on this line is odd to me

@jasnell

jasnell Apr 18, 2017

Member

Minor nit, feel free to ignore but the indenting on this line is odd to me

This comment has been minimized.

@addaleax

addaleax Apr 18, 2017

Member

It’s odd to me too, I’ll gladly take suggestions. (Maybe just splitting the statement into multiple ones is the best way…)

@addaleax

addaleax Apr 18, 2017

Member

It’s odd to me too, I’ll gladly take suggestions. (Maybe just splitting the statement into multiple ones is the best way…)

This comment has been minimized.

@gsathya

gsathya Apr 18, 2017

Member

if you restructure this to return early, then indentation becomes better.

void PromiseHook(..) {
  if (kResolve) { return; }
  if (kInit) {
    ... set value on promise...
    return;
  }

  .. code to get domain ..
  Local<Value> lookup_string;
  if (kBefore) {
    lookup_string = env->enter_string();  
  } else { 
    lookup_string = env->exit_string();
  }
  
  Local<Value> fun = domain->Get(context, lookup_string).ToLocalChecked();
  if(!fun->IsFunction()) { return; }
  if(fun.As<Function>()->Call(context, domain, 0, nullptr).IsEmpty()) {
   ....
  } 
}
@gsathya

gsathya Apr 18, 2017

Member

if you restructure this to return early, then indentation becomes better.

void PromiseHook(..) {
  if (kResolve) { return; }
  if (kInit) {
    ... set value on promise...
    return;
  }

  .. code to get domain ..
  Local<Value> lookup_string;
  if (kBefore) {
    lookup_string = env->enter_string();  
  } else { 
    lookup_string = env->exit_string();
  }
  
  Local<Value> fun = domain->Get(context, lookup_string).ToLocalChecked();
  if(!fun->IsFunction()) { return; }
  if(fun.As<Function>()->Call(context, domain, 0, nullptr).IsEmpty()) {
   ....
  } 
}
@ofrobots

This comment has been minimized.

Show comment
Hide comment
@ofrobots

ofrobots Apr 18, 2017

Contributor

Adding @gsathya for PromiseHooks. /cc @matthewloring

Contributor

ofrobots commented Apr 18, 2017

Adding @gsathya for PromiseHooks. /cc @matthewloring

Show outdated Hide outdated src/node.cc
if (type == PromiseHookType::kInit && env->in_domain()) {
promise->Set(context,
env->domain_string(),
env->domain_array()->Get(0)).FromJust();

This comment has been minimized.

@TimothyGu

TimothyGu Apr 18, 2017

Member

I feel we should hide the domain property with a private symbol...

@TimothyGu

TimothyGu Apr 18, 2017

Member

I feel we should hide the domain property with a private symbol...

This comment has been minimized.

@addaleax

addaleax Apr 18, 2017

Member

Again, this is very much in line with what MakeCallback does/uses, and it makes it clear that this actually messes with the Promise object itself (I would want that to be visible). But if anybody feels strongly I can change this as well. ¯\_(ツ)_/¯

@addaleax

addaleax Apr 18, 2017

Member

Again, this is very much in line with what MakeCallback does/uses, and it makes it clear that this actually messes with the Promise object itself (I would want that to be visible). But if anybody feels strongly I can change this as well. ¯\_(ツ)_/¯

This comment has been minimized.

@jasnell

jasnell Apr 18, 2017

Member

I think in this case, exposing the domain would be the right thing to do for sake of consistency

@jasnell

jasnell Apr 18, 2017

Member

I think in this case, exposing the domain would be the right thing to do for sake of consistency

Show outdated Hide outdated src/node.cc
domain->Get(context, env->exit_string()).ToLocalChecked();
if (exit_v->IsFunction()) {
if (exit_v.As<Function>()->Call(context, domain, 0, nullptr)
.IsEmpty()) {

This comment has been minimized.

@gsathya

gsathya Apr 18, 2017

Member

if you restructure this to return early, then indentation becomes better.

void PromiseHook(..) {
  if (kResolve) { return; }
  if (kInit) {
    ... set value on promise...
    return;
  }

  .. code to get domain ..
  Local<Value> lookup_string;
  if (kBefore) {
    lookup_string = env->enter_string();  
  } else { 
    lookup_string = env->exit_string();
  }
  
  Local<Value> fun = domain->Get(context, lookup_string).ToLocalChecked();
  if(!fun->IsFunction()) { return; }
  if(fun.As<Function>()->Call(context, domain, 0, nullptr).IsEmpty()) {
   ....
  } 
}
@gsathya

gsathya Apr 18, 2017

Member

if you restructure this to return early, then indentation becomes better.

void PromiseHook(..) {
  if (kResolve) { return; }
  if (kInit) {
    ... set value on promise...
    return;
  }

  .. code to get domain ..
  Local<Value> lookup_string;
  if (kBefore) {
    lookup_string = env->enter_string();  
  } else { 
    lookup_string = env->exit_string();
  }
  
  Local<Value> fun = domain->Get(context, lookup_string).ToLocalChecked();
  if(!fun->IsFunction()) { return; }
  if(fun.As<Function>()->Call(context, domain, 0, nullptr).IsEmpty()) {
   ....
  } 
}
Show outdated Hide outdated src/node.cc
Environment* env = Environment::GetCurrent(Isolate::GetCurrent());
Local<Context> context = env->context();
if (type == PromiseHookType::kInit && env->in_domain()) {

This comment has been minimized.

@gsathya

gsathya Apr 18, 2017

Member

Again, I don't have much context, but in_domain() check seems important, are you sure you don't need to do it for the other cases?

@gsathya

gsathya Apr 18, 2017

Member

Again, I don't have much context, but in_domain() check seems important, are you sure you don't need to do it for the other cases?

This comment has been minimized.

@addaleax

addaleax Apr 18, 2017

Member

I’m pretty sure, yes. This is based on existing code for similar circumstances (plain JS calls coming from the void), and in_domain() will automatically be true between the enter and exit callbacks.

@addaleax

addaleax Apr 18, 2017

Member

I’m pretty sure, yes. This is based on existing code for similar circumstances (plain JS calls coming from the void), and in_domain() will automatically be true between the enter and exit callbacks.

Show outdated Hide outdated src/node.cc
@@ -1110,6 +1111,57 @@ bool ShouldAbortOnUncaughtException(Isolate* isolate) {
}
void PromiseHook(PromiseHookType type,
Local<Promise> promise,
Local<Value> parent) {

This comment has been minimized.

@gsathya

gsathya Apr 18, 2017

Member

Don't have much context about domains but, AFAICS, the promise nor the parent is passed to the domain callback. Is that ok?

@gsathya

gsathya Apr 18, 2017

Member

Don't have much context about domains but, AFAICS, the promise nor the parent is passed to the domain callback. Is that ok?

This comment has been minimized.

@addaleax

addaleax Apr 18, 2017

Member

The domain enter/exit callbacks don’t do much, they basically just push or pop an object to an array.

@addaleax

addaleax Apr 18, 2017

Member

The domain enter/exit callbacks don’t do much, they basically just push or pop an object to an array.

@gsathya

This comment has been minimized.

Show comment
Hide comment
@gsathya

gsathya Apr 18, 2017

Member

Aside: It seems like a V8 design bug that Isolate::SetPromiseHook()/PromiseHook() don’t take a void* data opaque, does anybody agree? I’d probably like to change that in V8 then. (Also, same question for Isolate::SetPromiseRejectCallback()… am I missing something? This can’t be intentional, right?)

I didn't see the need for this when designing the API. Please file a V8 bug with a use case. I can take a look.

Member

gsathya commented Apr 18, 2017

Aside: It seems like a V8 design bug that Isolate::SetPromiseHook()/PromiseHook() don’t take a void* data opaque, does anybody agree? I’d probably like to change that in V8 then. (Also, same question for Isolate::SetPromiseRejectCallback()… am I missing something? This can’t be intentional, right?)

I didn't see the need for this when designing the API. Please file a V8 bug with a use case. I can take a look.

@matthewloring

This comment has been minimized.

Show comment
Hide comment
@matthewloring

matthewloring Apr 18, 2017

Contributor

It would be good to coordinate this work with the async hooks work here: #11883. Node can only register one set of promise hook callbacks (by design) so the callbacks will have to handle emitting the right async hooks lifecycle events in addition to propagating domains (if desired).

I have been prototyping promise hook integration for async hooks on top of #11883. I have experimented with refactoring AsyncWrap::MakeCallback into "before callback invocation" and "after callback invocation" helpers since they already have the correct domain propagation and emit the correct async hook events. Once refactored, these functions could then be called from the kBefore and kAfter promise hook callbacks. This approach won't be able to use the existing AsyncHooks::ExecScope mechanism but I think we can work around this. What do you think about this design?

Contributor

matthewloring commented Apr 18, 2017

It would be good to coordinate this work with the async hooks work here: #11883. Node can only register one set of promise hook callbacks (by design) so the callbacks will have to handle emitting the right async hooks lifecycle events in addition to propagating domains (if desired).

I have been prototyping promise hook integration for async hooks on top of #11883. I have experimented with refactoring AsyncWrap::MakeCallback into "before callback invocation" and "after callback invocation" helpers since they already have the correct domain propagation and emit the correct async hook events. Once refactored, these functions could then be called from the kBefore and kAfter promise hook callbacks. This approach won't be able to use the existing AsyncHooks::ExecScope mechanism but I think we can work around this. What do you think about this design?

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Apr 18, 2017

Member

I didn't see the need for this when designing the API. Please file a V8 bug with a use case. I can take a look.

Well, it forces consumers to use global state, or Isolate::GetCurrent() or similar to access any interesting data, which I would consider an anti-pattern (and, as I have recently learned, Isolate::GetCurrent() is something V8 would generally like to migrate away from), which is why it’s good practice to provide an opaque pointer to plain callbacks in C++ for those reasons. I’m happy to submit a V8 patch myself.

What do you think about this design?

@matthewloring Sounds good, I’d be curious to see what you have come up with.

Member

addaleax commented Apr 18, 2017

I didn't see the need for this when designing the API. Please file a V8 bug with a use case. I can take a look.

Well, it forces consumers to use global state, or Isolate::GetCurrent() or similar to access any interesting data, which I would consider an anti-pattern (and, as I have recently learned, Isolate::GetCurrent() is something V8 would generally like to migrate away from), which is why it’s good practice to provide an opaque pointer to plain callbacks in C++ for those reasons. I’m happy to submit a V8 patch myself.

What do you think about this design?

@matthewloring Sounds good, I’d be curious to see what you have come up with.

@gsathya

This comment has been minimized.

Show comment
Hide comment
@gsathya

gsathya Apr 18, 2017

Member

Well, it forces consumers to use global state, or Isolate::GetCurrent() or similar to access any interesting data, which I would consider an anti-pattern (and, as I have recently learned, Isolate::GetCurrent() is something V8 would generally like to migrate away from), which is why it’s good practice to provide an opaque pointer to plain callbacks in C++ for those reasons.

There's only one possible promisehook that can be used so global state isn't the worst, but the embedder is free to create better encapsulation if required. Also, you can get the isolate from the promise object directly, no need for Isolate::GetCurrent(). Anyways, this is better discussed in a V8 bug.

Member

gsathya commented Apr 18, 2017

Well, it forces consumers to use global state, or Isolate::GetCurrent() or similar to access any interesting data, which I would consider an anti-pattern (and, as I have recently learned, Isolate::GetCurrent() is something V8 would generally like to migrate away from), which is why it’s good practice to provide an opaque pointer to plain callbacks in C++ for those reasons.

There's only one possible promisehook that can be used so global state isn't the worst, but the embedder is free to create better encapsulation if required. Also, you can get the isolate from the promise object directly, no need for Isolate::GetCurrent(). Anyways, this is better discussed in a V8 bug.

@bnoordhuis

LGTM modulo comments.

Show outdated Hide outdated src/node.cc
void PromiseHook(PromiseHookType type,
Local<Promise> promise,
Local<Value> parent) {
Environment* env = Environment::GetCurrent(Isolate::GetCurrent());

This comment has been minimized.

@bnoordhuis

bnoordhuis Apr 18, 2017

Member

I think it should be safe (and a little more efficient) to call Environment::GetCurrent(promise->CreationContext()).

(It must be safe because some of the operations in this function will error without a HandleScope. I think the promise hook implicitly runs inside one.)

@bnoordhuis

bnoordhuis Apr 18, 2017

Member

I think it should be safe (and a little more efficient) to call Environment::GetCurrent(promise->CreationContext()).

(It must be safe because some of the operations in this function will error without a HandleScope. I think the promise hook implicitly runs inside one.)

Show outdated Hide outdated src/node.cc
if (type == PromiseHookType::kInit && env->in_domain()) {
promise->Set(context,
env->domain_string(),
env->domain_array()->Get(0)).FromJust();

This comment has been minimized.

@bnoordhuis

bnoordhuis Apr 18, 2017

Member

Get(context, 0).ToLocalChecked()

@bnoordhuis

bnoordhuis Apr 18, 2017

Member

Get(context, 0).ToLocalChecked()

Show outdated Hide outdated test/parallel/test-domain-promise.js
Promise.resolve().then(common.mustCall(() => {
assert.strictEqual(process.domain, d);
}));
}));

This comment has been minimized.

@bnoordhuis

bnoordhuis Apr 18, 2017

Member

It would be good to check that domains + promises + vm.runInNewContext() also does the right thing.

@bnoordhuis

bnoordhuis Apr 18, 2017

Member

It would be good to check that domains + promises + vm.runInNewContext() also does the right thing.

@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Apr 19, 2017

Contributor

FWIW, I'm generally in favor of this change. Some (including myself!) have built continuation-local-storage-on-the-cheap on top of domains, & end up having to strictly enforce domain-compliant promise library use. This gives us a good road forward to move onto native promises, and from there onto asynchooks.

Contributor

chrisdickinson commented Apr 19, 2017

FWIW, I'm generally in favor of this change. Some (including myself!) have built continuation-local-storage-on-the-cheap on top of domains, & end up having to strictly enforce domain-compliant promise library use. This gives us a good road forward to move onto native promises, and from there onto asynchooks.

@benjamingr benjamingr referenced this pull request Apr 19, 2017

Merged

util: add util.promisify() #12442

4 of 4 tasks complete
@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Apr 19, 2017

Member

@bnoordhuis I should have addressed your comments

CI: https://ci.nodejs.org/job/node-test-commit/9232/

Member

addaleax commented Apr 19, 2017

@bnoordhuis I should have addressed your comments

CI: https://ci.nodejs.org/job/node-test-commit/9232/

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Apr 19, 2017

Member

This should likely include some documentation added to doc/api/domain.md to explain how to make use of this and the various caveats.

Member

jasnell commented Apr 19, 2017

This should likely include some documentation added to doc/api/domain.md to explain how to make use of this and the various caveats.

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Apr 19, 2017

Member

@jasnell mind clarifying?

Member

benjamingr commented Apr 19, 2017

@jasnell mind clarifying?

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Apr 19, 2017

Member

Really just an example similar to what is in the test, a quick explanation of what it means, and a quick explanation of how error handling works with a domain-aware Promise. It doesn't have to be too detailed.

Member

jasnell commented Apr 19, 2017

Really just an example similar to what is in the test, a quick explanation of what it means, and a quick explanation of how error handling works with a domain-aware Promise. It doesn't have to be too detailed.

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Apr 19, 2017

Member

a quick explanation of how error handling works with a domain-aware Promise

@jasnell To avoid any misunderstandings – this does not touch Promise error handling in any way. All it means that code in a then() or catch() handler “knows” the domain in which the head of the promise chain has been created handler has been attached, and code inside that handlers runs in that domain. I’ve added a small changes: tag to the doc, though.

Member

addaleax commented Apr 19, 2017

a quick explanation of how error handling works with a domain-aware Promise

@jasnell To avoid any misunderstandings – this does not touch Promise error handling in any way. All it means that code in a then() or catch() handler “knows” the domain in which the head of the promise chain has been created handler has been attached, and code inside that handlers runs in that domain. I’ve added a small changes: tag to the doc, though.

@NatalieWolfe

This comment has been minimized.

Show comment
Hide comment
@NatalieWolfe

NatalieWolfe Apr 19, 2017

Would it be possible to expose the domain's promise hook function in the headers for other modules to call? Unless AsyncWrap lands in 8 as well, other libraries that manage asynchronous contexts will need to add their own PromiseHook. Since there can be only one hook, and there is no way to get the current hook when adding your own, other libraries need a way to manually call the domain hook from within their own if domains are in use.

Either that, or expose a new API on top of promise hook that allows multiple hooks at once as a stop-gap until AsyncWrap is in.

Would it be possible to expose the domain's promise hook function in the headers for other modules to call? Unless AsyncWrap lands in 8 as well, other libraries that manage asynchronous contexts will need to add their own PromiseHook. Since there can be only one hook, and there is no way to get the current hook when adding your own, other libraries need a way to manually call the domain hook from within their own if domains are in use.

Either that, or expose a new API on top of promise hook that allows multiple hooks at once as a stop-gap until AsyncWrap is in.

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Apr 19, 2017

Member

Would it be possible to expose the domain's promise hook function in the headers for other modules to call?

Yes, but whatever we implement in Node is going to stick around for a long time, I’m not sure we’d want to do it that way… (also, fwiw, I think it should be pretty doable to implement a PromiseHook that does what this one does exclusively using public Node APIs).

Unless AsyncWrap lands in 8 as well, other libraries that manage asynchronous contexts will need to add their own PromiseHook.

It seems to me like there’s a good chance it does… @trevnorris ? Are you talking about libraries that use the current async_wrap API or something else (if something else: how do they currently manage wrapping MakeCallback())?

Either that, or expose a new API on top of promise hook that allows multiple hooks at once as a stop-gap until AsyncWrap is in.

That sounds like the best option to me (iff async_hooks doesn’t make it?). Does anybody here have strong feelings either way?

Member

addaleax commented Apr 19, 2017

Would it be possible to expose the domain's promise hook function in the headers for other modules to call?

Yes, but whatever we implement in Node is going to stick around for a long time, I’m not sure we’d want to do it that way… (also, fwiw, I think it should be pretty doable to implement a PromiseHook that does what this one does exclusively using public Node APIs).

Unless AsyncWrap lands in 8 as well, other libraries that manage asynchronous contexts will need to add their own PromiseHook.

It seems to me like there’s a good chance it does… @trevnorris ? Are you talking about libraries that use the current async_wrap API or something else (if something else: how do they currently manage wrapping MakeCallback())?

Either that, or expose a new API on top of promise hook that allows multiple hooks at once as a stop-gap until AsyncWrap is in.

That sounds like the best option to me (iff async_hooks doesn’t make it?). Does anybody here have strong feelings either way?

Show outdated Hide outdated test/parallel/test-domain-promise.js
const vm = require('vm');
const d = domain.create();

This comment has been minimized.

@matthewloring

matthewloring Apr 19, 2017

Contributor

If I understand the promise hooks correctly above, the following should be true under the current implementation:

const d1 = domain.create();
const d2 = domain.create();

var p;
d1.run(() => {
  p = Promise.resolve(42);
});

d2.run(() => {
  p.then((v) => {
    // running in d2
  });
});

An equally valid way of propagating domains would be for the callback passed to then to run in the domain of its parent promise. With either default behavior it is possible to have the callback run in either context (by binding it explicitly) so I don't think this is a fundamental limitation. It would probably be good to describe this design choice and document how to work around it in any documentation that is added as part of this PR.

@matthewloring

matthewloring Apr 19, 2017

Contributor

If I understand the promise hooks correctly above, the following should be true under the current implementation:

const d1 = domain.create();
const d2 = domain.create();

var p;
d1.run(() => {
  p = Promise.resolve(42);
});

d2.run(() => {
  p.then((v) => {
    // running in d2
  });
});

An equally valid way of propagating domains would be for the callback passed to then to run in the domain of its parent promise. With either default behavior it is possible to have the callback run in either context (by binding it explicitly) so I don't think this is a fundamental limitation. It would probably be good to describe this design choice and document how to work around it in any documentation that is added as part of this PR.

This comment has been minimized.

@matthewloring

matthewloring Apr 20, 2017

Contributor

@addaleax @trevnorris Here is the work I have so far on integrating promise hooks with async hooks: matthewloring@dd17833#diff-5e552c79e1538215f1621d1774852e71R260. It is still very much a work in progress but the high level structure is all there. It provides both async hooks and domain propagation using the same mechanism and behavior as async wrap.

@matthewloring

matthewloring Apr 20, 2017

Contributor

@addaleax @trevnorris Here is the work I have so far on integrating promise hooks with async hooks: matthewloring@dd17833#diff-5e552c79e1538215f1621d1774852e71R260. It is still very much a work in progress but the high level structure is all there. It provides both async hooks and domain propagation using the same mechanism and behavior as async wrap.

This comment has been minimized.

@addaleax

addaleax Apr 21, 2017

Member

@matthewloring thanks for letting us know, looks pretty sensible to me :) Also seems pretty doable to integrate it with the work in this PR

@addaleax

addaleax Apr 21, 2017

Member

@matthewloring thanks for letting us know, looks pretty sensible to me :) Also seems pretty doable to integrate it with the work in this PR

@NatalieWolfe

This comment has been minimized.

Show comment
Hide comment
@NatalieWolfe

NatalieWolfe Apr 19, 2017

@addaleax While we could re-implement the domain promise hook using existing APIs, we would then have to make sure our code keeps up with any changes that may happen here.

If AsyncWrap is going to be in 8, wouldn't it make more sense to put the promise hook in there and have domains rely upon that? Or finally truly deprecate domains. :)

By "other libraries that manage asynchronous contexts" I am mostly referring to APM modules, such as the one I work on. We would not wrap AsyncWrap::MakeCallback but instead use async wrap to get hooks that are otherwise unavailable in JS-land, such as PromiseHook.

@addaleax While we could re-implement the domain promise hook using existing APIs, we would then have to make sure our code keeps up with any changes that may happen here.

If AsyncWrap is going to be in 8, wouldn't it make more sense to put the promise hook in there and have domains rely upon that? Or finally truly deprecate domains. :)

By "other libraries that manage asynchronous contexts" I am mostly referring to APM modules, such as the one I work on. We would not wrap AsyncWrap::MakeCallback but instead use async wrap to get hooks that are otherwise unavailable in JS-land, such as PromiseHook.

@misterdjules

This comment has been minimized.

Show comment
Hide comment
@misterdjules

misterdjules Apr 19, 2017

@addaleax The overall implementation looks good to me. I would like to see more tests with the following:

  • nested domains
  • rejected promises. Not testing that domains would intercept errors in this case, I know this PR is not about that, but making sure that if more promise handlers are executed after a promise was rejected, they are associated to the right domain
  • maybe promises running within domains that also schedule other types of async operations (like timers callbacks, file I/O, network I/O, etc.). The goal would be to make sure that the code that is handling domains in *::MakeCallback works with the one added in this PR

Thank you very much for doing this!

@addaleax The overall implementation looks good to me. I would like to see more tests with the following:

  • nested domains
  • rejected promises. Not testing that domains would intercept errors in this case, I know this PR is not about that, but making sure that if more promise handlers are executed after a promise was rejected, they are associated to the right domain
  • maybe promises running within domains that also schedule other types of async operations (like timers callbacks, file I/O, network I/O, etc.). The goal would be to make sure that the code that is handling domains in *::MakeCallback works with the one added in this PR

Thank you very much for doing this!

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Apr 19, 2017

Member

this does not touch Promise error handling in any way. All it means that code in a then() or catch() handler “knows” the domain in which the head of the promise chain has been created, and code inside that handlers runs in that domain

@addaleax ... :-) to be clear, I know that, but it would be good to make sure the docs clearly indicate that fact. I generally want to avoid the potential confusion and questions later.

Member

jasnell commented Apr 19, 2017

this does not touch Promise error handling in any way. All it means that code in a then() or catch() handler “knows” the domain in which the head of the promise chain has been created, and code inside that handlers runs in that domain

@addaleax ... :-) to be clear, I know that, but it would be good to make sure the docs clearly indicate that fact. I generally want to avoid the potential confusion and questions later.

@ORESoftware

This comment has been minimized.

Show comment
Hide comment
@ORESoftware

ORESoftware Apr 20, 2017

Semantical nitpick here, shouldn't the title of this pull/issue be:

V8 promises: support domains

instead of domain: support promises?
:)

Or am I wrong?

ORESoftware commented Apr 20, 2017

Semantical nitpick here, shouldn't the title of this pull/issue be:

V8 promises: support domains

instead of domain: support promises?
:)

Or am I wrong?

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Apr 27, 2017

Member

@benjamingr You mean, #12442? Not unless @misterdjules withdraws his objection or we bring it to a CTC vote (which we have a bit of time for, since the release it’s obviously targeting is Node 8, so we should be fine giving it one or two weeks more).

Member

addaleax commented Apr 27, 2017

@benjamingr You mean, #12442? Not unless @misterdjules withdraws his objection or we bring it to a CTC vote (which we have a bit of time for, since the release it’s obviously targeting is Node 8, so we should be fine giving it one or two weeks more).

@@ -675,3 +675,9 @@ exports.getArrayBufferViews = function getArrayBufferViews(buf) {
}
return out;
};
// Crash the process on unhandled rejections.
exports.crashOnUnhandledRejection = function() {

This comment has been minimized.

@Trott

Trott Apr 27, 2017

Member

Documentation for this should be added to test/README.md.

@Trott

Trott Apr 27, 2017

Member

Documentation for this should be added to test/README.md.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Apr 27, 2017

Member

Note: if #12442 is going to land in 8.0.0, ideally it would land before May 9th, so if we're going to have to bring it to a CTC vote, we should likely do that sooner than later.

Member

jasnell commented Apr 27, 2017

Note: if #12442 is going to land in 8.0.0, ideally it would land before May 9th, so if we're going to have to bring it to a CTC vote, we should likely do that sooner than later.

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Apr 27, 2017

Member

@jasnell It’s not a semver-major change, so I don’t know if you plan on applying the same rules to it. I have that date in the back of my head, though … I’d like to see where the discussion goes in nodejs/CTC#114 and try a couple of things for improved Post-Mortem debugging out myself, and maybe see if @misterdjules’ concerns can be alleviated through actual improvements rather than just talking him over. :)

If you, as the releaser, want May 9th to be a fixed deadline for that particular semver-minor, then voting in the next @nodejs/ctc meeting sounds good (otherwise probably the one after that).

Member

addaleax commented Apr 27, 2017

@jasnell It’s not a semver-major change, so I don’t know if you plan on applying the same rules to it. I have that date in the back of my head, though … I’d like to see where the discussion goes in nodejs/CTC#114 and try a couple of things for improved Post-Mortem debugging out myself, and maybe see if @misterdjules’ concerns can be alleviated through actual improvements rather than just talking him over. :)

If you, as the releaser, want May 9th to be a fixed deadline for that particular semver-minor, then voting in the next @nodejs/ctc meeting sounds good (otherwise probably the one after that).

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Apr 27, 2017

Member

Not strictly, but I'd like to be able to start proper release candidates as soon as possible, and for something as potentially important as this, I'd like to get it into the hands of testers as early as possible.

Member

jasnell commented Apr 27, 2017

Not strictly, but I'd like to be able to start proper release candidates as soon as possible, and for something as potentially important as this, I'd like to get it into the hands of testers as early as possible.

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Apr 27, 2017

Member

I definitely haven't planned to talk anyone over and I take the post mortem concerns very seriously.

I'd like to see how we can address the post-mortem concerns, I think CoW snapshots on rejections that have no catch handler attached synchronously under a flag (or in an async function) is a viable strategy which encompasses the vast majority of promise use while solving the post-mortem problems and would actually provide a better solution.

The problem is I'm not sure how to technically approach and start this - and we have established that the PR has no impact on the post-mortem problem.

I'd also like to suggest an .isOperational flag for util.promisify which would signal errors originating in the core API and would interop with bluebird's .error and promisify - this would enable us to terminate the process on errors not originating in APIs.

These two ideas are still not really formulated in my brain enough to suggest them in either thread.

Member

benjamingr commented Apr 27, 2017

I definitely haven't planned to talk anyone over and I take the post mortem concerns very seriously.

I'd like to see how we can address the post-mortem concerns, I think CoW snapshots on rejections that have no catch handler attached synchronously under a flag (or in an async function) is a viable strategy which encompasses the vast majority of promise use while solving the post-mortem problems and would actually provide a better solution.

The problem is I'm not sure how to technically approach and start this - and we have established that the PR has no impact on the post-mortem problem.

I'd also like to suggest an .isOperational flag for util.promisify which would signal errors originating in the core API and would interop with bluebird's .error and promisify - this would enable us to terminate the process on errors not originating in APIs.

These two ideas are still not really formulated in my brain enough to suggest them in either thread.

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Apr 27, 2017

Member

@benjamingr Yeah, sorry, that might not have come over quite right. I wasn’t targeting you with that comment, rather myself (because I’m the one pushing for this feature right now and I haven’t really helped the Post-Mortem discussion a lot so far, if we’re being honest).

The problem is I'm not sure how to technically approach and start this - and we have established that the PR has no impact on the post-mortem problem.

Yeah, once you think your plans are concrete enough, I would be glad to help implement them. Also, yes, the PR has no direct relation to post-mortem, but the reason we might need to vote is that there are people for whom these two things are tied together.

Member

addaleax commented Apr 27, 2017

@benjamingr Yeah, sorry, that might not have come over quite right. I wasn’t targeting you with that comment, rather myself (because I’m the one pushing for this feature right now and I haven’t really helped the Post-Mortem discussion a lot so far, if we’re being honest).

The problem is I'm not sure how to technically approach and start this - and we have established that the PR has no impact on the post-mortem problem.

Yeah, once you think your plans are concrete enough, I would be glad to help implement them. Also, yes, the PR has no direct relation to post-mortem, but the reason we might need to vote is that there are people for whom these two things are tied together.

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Apr 27, 2017

Member

@gsathya This isn’t related to the functionality exposed by this PR, but the kInit and kResolve behaviour looks a bit odd: It seems like Promise.reject(42) calls both with a Promise rejected with 42, but Promise.resolve(42) calls both while the Promise is still pending. Is that intentional?

Member

addaleax commented Apr 27, 2017

@gsathya This isn’t related to the functionality exposed by this PR, but the kInit and kResolve behaviour looks a bit odd: It seems like Promise.reject(42) calls both with a Promise rejected with 42, but Promise.resolve(42) calls both while the Promise is still pending. Is that intentional?

@gsathya

This comment has been minimized.

Show comment
Hide comment
@gsathya

gsathya Apr 27, 2017

Member

Yeah, this is expected. V8 optimizes the reject case by creating a promise that is already rejected since we don't have to perform the PromiseResolveThenableJob dance. This isn't observable to any userland js.

Member

gsathya commented Apr 27, 2017

Yeah, this is expected. V8 optimizes the reject case by creating a promise that is already rejected since we don't have to perform the PromiseResolveThenableJob dance. This isn't observable to any userland js.

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Apr 27, 2017

Member

@gsathya Would it make sense/be possible to call the kResolve callback when the promise actually gets resolve? If not, I’m not sure how useful kResolve is given that it doesn’t provide much information about what’s actually happening with the promise (or am I mistaken)?

Member

addaleax commented Apr 27, 2017

@gsathya Would it make sense/be possible to call the kResolve callback when the promise actually gets resolve? If not, I’m not sure how useful kResolve is given that it doesn’t provide much information about what’s actually happening with the promise (or am I mistaken)?

@gsathya

This comment has been minimized.

Show comment
Hide comment
@gsathya

gsathya Apr 27, 2017

Member

Would it make sense/be possible to call the kResolve callback when the promise actually gets resolve?

Not sure I follow. Can you point to the exact step in the spec?

If not, I’m not sure how useful kResolve is given that it doesn’t provide much information about what’s actually happening with the promise (or am I mistaken)?

The only real use of the resolve hook is to provide information about who is triggering the promise resolving functions (to stitch together better stack traces).

var res;
new Promise(r => res = r ).then(console.log)
function foo() { res(1); }
foo();

with the resolve hook, you can figure out that foo() triggered the promise resolving function.

Member

gsathya commented Apr 27, 2017

Would it make sense/be possible to call the kResolve callback when the promise actually gets resolve?

Not sure I follow. Can you point to the exact step in the spec?

If not, I’m not sure how useful kResolve is given that it doesn’t provide much information about what’s actually happening with the promise (or am I mistaken)?

The only real use of the resolve hook is to provide information about who is triggering the promise resolving functions (to stitch together better stack traces).

var res;
new Promise(r => res = r ).then(console.log)
function foo() { res(1); }
foo();

with the resolve hook, you can figure out that foo() triggered the promise resolving function.

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Apr 27, 2017

Member

@gsathya My intuition would be that kResolve would make more sense as acting like an extra step after [[PromiseState]] is set to "fulfilled" or "rejected" in FulfillPromise and RejectPromise, respectively (rather than at the beginning of those functions, if I understand the V8 header comment correctly).

That should give the same stack traces etc., but carrying the additional information of the actual new Promise state.

Member

addaleax commented Apr 27, 2017

@gsathya My intuition would be that kResolve would make more sense as acting like an extra step after [[PromiseState]] is set to "fulfilled" or "rejected" in FulfillPromise and RejectPromise, respectively (rather than at the beginning of those functions, if I understand the V8 header comment correctly).

That should give the same stack traces etc., but carrying the additional information of the actual new Promise state.

@gsathya

This comment has been minimized.

Show comment
Hide comment
@gsathya

gsathya Apr 27, 2017

Member

That should give the same stack traces etc., but carrying the additional information of the actual new Promise state.

var res;
var x = new Promise(r => res = r);
function foo() { res(new Promise(r => setTimeout(r))); };
foo();

x won't be resolved until later by which time we lose the stack.

Member

gsathya commented Apr 27, 2017

That should give the same stack traces etc., but carrying the additional information of the actual new Promise state.

var res;
var x = new Promise(r => res = r);
function foo() { res(new Promise(r => setTimeout(r))); };
foo();

x won't be resolved until later by which time we lose the stack.

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins May 15, 2017

Member

@addaleax would you consider backporting dca0815 to v6.x

Member

MylesBorins commented May 15, 2017

@addaleax would you consider backporting dca0815 to v6.x

addaleax added a commit to addaleax/node that referenced this pull request May 18, 2017

test: introduce `common.crashOnUnhandledRejection`
Ref: nodejs#12442
PR-URL: nodejs#12489
Reviewed-By: Matthew Loring <mattloring@google.com>
Reviewed-By: Julien Gilli <jgilli@nodejs.org>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

addaleax added a commit to addaleax/node that referenced this pull request May 18, 2017

test: introduce `common.crashOnUnhandledRejection`
Ref: nodejs#12442
PR-URL: nodejs#12489
Reviewed-By: Matthew Loring <mattloring@google.com>
Reviewed-By: Julien Gilli <jgilli@nodejs.org>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

@jasnell jasnell referenced this pull request May 11, 2017

Closed

8.0.0 Release Proposal #12220

jasnell added a commit to jasnell/node that referenced this pull request May 29, 2017

2017-05-30, Version 8.0.0 (Current)
* **Async Hooks**
  * The `async_hooks` module has landed in core
    [[`4a7233c178`](nodejs@4a7233c]
    [#12892](nodejs#12892).

* **Buffer**
  * Using the `--pending-deprecation` flag will cause Node.js to emit a
    deprecation warning when using `new Buffer(num)` or `Buffer(num)`.
    [[`d2d32ea5a2`](nodejs@d2d32ea]
    [#11968](nodejs#11968).
  * `new Buffer(num)` and `Buffer(num)` will zero-fill new `Buffer` instances
    [[`7eb1b4658e`](nodejs@7eb1b46]
    [#12141](nodejs#12141).
  * Many `Buffer` methods now accept `Uint8Array` as input
    [[`beca3244e2`](nodejs@beca324]
    [#10236](nodejs#10236).

* **Child Process**
  * Argument and kill signal validations have been improved
    [[`97a77288ce`](nodejs@97a7728]
    [#12348](nodejs#12348),
    [[`d75fdd96aa`](nodejs@d75fdd9]
    [#10423](nodejs#10423).
  * Child Process methods accept `Uint8Array` as input
    [[`627ecee9ed`](nodejs@627ecee]
    [#10653](nodejs#10653).

* **Console**
  * Error events emitted when using `console` methods are now supressed.
    [[`f18e08d820`](nodejs@f18e08d]
    [#9744](nodejs#9744).

* **Dependencies**
  * The npm client has been updated to 5.0.0
    [[`3c3b36af0f`](nodejs@3c3b36a]
    [#12936](nodejs#12936).
  * V8 has been updated to 5.8 with forward ABI stability to 6.0
    [[`60d1aac8d2`](nodejs@60d1aac]
    [#12784](nodejs#12784).

* **Domains**
  * Native `Promise` instances are now `Domain` aware
    [[`84dabe8373`](nodejs@84dabe8]
    [#12489](nodejs#12489).

* **Errors**
  * We have started assigning static error codes to errors generated by Node.js.
    This has been done through multiple commits and is still a work in
    progress.

* **File System**
  * The utility class `fs.SyncWriteStream` has been deprecated
    [[`7a55e34ef4`](nodejs@7a55e34]
    [#10467](nodejs#10467).
  * The deprecated `fs.read()` string interface has been removed
    [[`3c2a9361ff`](nodejs@3c2a936]
    [#9683](nodejs#9683).

* **HTTP**
  * Improved support for userland implemented Agents
    [[`90403dd1d0`](nodejs@90403dd]
    [#11567](nodejs#11567).
  * Outgoing Cookie headers are concatenated into a single string
    [[`d3480776c7`](nodejs@d348077]
    [#11259](nodejs#11259).
  * The `httpResponse.writeHeader()` method has been deprecated
    [[`fb71ba4921`](nodejs@fb71ba4]
    [#11355](nodejs#11355).
  * New methods for accessing HTTP headers have been added to `OutgoingMessage`
    [[`3e6f1032a4`](nodejs@3e6f103]
    [#10805](nodejs#10805).

* **Lib**
  * All deprecation messages have been assigned static identifiers
    [[`5de3cf099c`](nodejs@5de3cf0]
    [#10116](nodejs#10116).
  * The legacy `linkedlist` module has been removed
    [[`84a23391f6`](nodejs@84a2339]
    [#12113](nodejs#12113).

* **N-API**
  * Experimental support for the new N-API API has been added
    [[`56e881d0b0`](nodejs@56e881d]
    [#11975](nodejs#11975).

* **Process**
  * Process warning output can be redirected to a file using the
    `--redirect-warnings` command-line argument
    [[`03e89b3ff2`](nodejs@03e89b3]
    [#10116](nodejs#10116).
  * Process warnings may now include additional detail
    [[`dd20e68b0f`](nodejs@dd20e68]
    [#12725](nodejs#12725).

* **REPL**
  * REPL magic mode has been deprecated
    [[`3f27f02da0`](nodejs@3f27f02]
    [#11599](nodejs#11599).

* **Src**
  * `NODE_MODULE_VERSION` has been updated to 57
    (nodejs@ec7cbaf]
    [#12995](nodejs#12995).
  * Add `--pending-deprecation` command-line argument and
    `NODE_PENDING_DEPRECATION` environment variable
    [[`a16b570f8c`](nodejs@a16b570]
    [#11968](nodejs#11968).
  * The `--debug` command-line argument has been deprecated. Note that
    using `--debug` will enable the *new* Inspector-based debug protocol
    as the legacy Debugger protocol previously used by Node.js has been
    removed. [[`010f864426`](nodejs@010f864]
    [#12949](nodejs#12949).
  * Throw when the `-c` and `-e` command-line arguments are used at the same
    time [[`a5f91ab230`](nodejs@a5f91ab]
    [#11689](nodejs#11689).
  * Throw when the `--use-bundled-ca` and `--use-openssl-ca` command-line
    arguments are used at the same time.
    [[`8a7db9d4b5`](nodejs@8a7db9d]
    [#12087](nodejs#12087).

* **Stream**
  * `Stream` now supports `destroy()` and `_destroy()` APIs
    [[`b6e1d22fa6`](nodejs@b6e1d22]
    [#12925](nodejs#12925).
  * `Stream` now supports the `_final()` API
    [[`07c7f198db`](nodejs@07c7f19]
    [#12828](nodejs#12828).

* **TLS**
  * The `rejectUnauthorized` option now defaults to `true`
    [[`348cc80a3c`](nodejs@348cc80]
    [#5923](nodejs#5923).
  * The `tls.createSecurePair()` API now emits a runtime deprecation
    [[`a2ae08999b`](nodejs@a2ae089]
    [#11349](nodejs#11349).
  * A runtime deprecation will now be emitted when `dhparam` is less than
    2048 bits [[`d523eb9c40`](nodejs@d523eb9]
    [#11447](nodejs#11447).

* **URL**
  * The WHATWG URL implementation is now a fully-supported Node.js API
    [[`d080ead0f9`](nodejs@d080ead]
    [#12710](nodejs#12710).

* **Util**
  * `Symbol` keys are now displayed by default when using `util.inspect()`
    [[`5bfd13b81e`](nodejs@5bfd13b]
    [#9726](nodejs#9726).
  * `toJSON` errors will be thrown when formatting `%j`
    [[`455e6f1dd8`](nodejs@455e6f1]
    [#11708](nodejs#11708).
  * Convert `inspect.styles` and `inspect.colors` to prototype-less objects
    [[`aab0d202f8`](nodejs@aab0d20]
    [#11624](nodejs#11624).
  * The new `util.promisify()` API has been added
    [[`99da8e8e02`](nodejs@99da8e8]
    [#12442](nodejs#12442).

* **Zlib**
  * Support `Uint8Array` in Zlib convenience methods
    [[`91383e47fd`](nodejs@91383e4]
    [#12001](nodejs#12001).
  * Zlib errors now use `RangeError` and `TypeError` consistently
    [[`b514bd231e`](nodejs@b514bd2]
    [#11391](nodejs#11391).

jasnell added a commit that referenced this pull request May 30, 2017

2017-05-30, Version 8.0.0 (Current)
* **Async Hooks**
  * The `async_hooks` module has landed in core
    [[`4a7233c178`](4a7233c]
    [#12892](#12892).

* **Buffer**
  * Using the `--pending-deprecation` flag will cause Node.js to emit a
    deprecation warning when using `new Buffer(num)` or `Buffer(num)`.
    [[`d2d32ea5a2`](d2d32ea]
    [#11968](#11968).
  * `new Buffer(num)` and `Buffer(num)` will zero-fill new `Buffer` instances
    [[`7eb1b4658e`](7eb1b46]
    [#12141](#12141).
  * Many `Buffer` methods now accept `Uint8Array` as input
    [[`beca3244e2`](beca324]
    [#10236](#10236).

* **Child Process**
  * Argument and kill signal validations have been improved
    [[`97a77288ce`](97a7728]
    [#12348](#12348),
    [[`d75fdd96aa`](d75fdd9]
    [#10423](#10423).
  * Child Process methods accept `Uint8Array` as input
    [[`627ecee9ed`](627ecee]
    [#10653](#10653).

* **Console**
  * Error events emitted when using `console` methods are now supressed.
    [[`f18e08d820`](f18e08d]
    [#9744](#9744).

* **Dependencies**
  * The npm client has been updated to 5.0.0
    [[`3c3b36af0f`](3c3b36a]
    [#12936](#12936).
  * V8 has been updated to 5.8 with forward ABI stability to 6.0
    [[`60d1aac8d2`](60d1aac]
    [#12784](#12784).

* **Domains**
  * Native `Promise` instances are now `Domain` aware
    [[`84dabe8373`](84dabe8]
    [#12489](#12489).

* **Errors**
  * We have started assigning static error codes to errors generated by Node.js.
    This has been done through multiple commits and is still a work in
    progress.

* **File System**
  * The utility class `fs.SyncWriteStream` has been deprecated
    [[`7a55e34ef4`](7a55e34]
    [#10467](#10467).
  * The deprecated `fs.read()` string interface has been removed
    [[`3c2a9361ff`](3c2a936]
    [#9683](#9683).

* **HTTP**
  * Improved support for userland implemented Agents
    [[`90403dd1d0`](90403dd]
    [#11567](#11567).
  * Outgoing Cookie headers are concatenated into a single string
    [[`d3480776c7`](d348077]
    [#11259](#11259).
  * The `httpResponse.writeHeader()` method has been deprecated
    [[`fb71ba4921`](fb71ba4]
    [#11355](#11355).
  * New methods for accessing HTTP headers have been added to `OutgoingMessage`
    [[`3e6f1032a4`](3e6f103]
    [#10805](#10805).

* **Lib**
  * All deprecation messages have been assigned static identifiers
    [[`5de3cf099c`](5de3cf0]
    [#10116](#10116).
  * The legacy `linkedlist` module has been removed
    [[`84a23391f6`](84a2339]
    [#12113](#12113).

* **N-API**
  * Experimental support for the new N-API API has been added
    [[`56e881d0b0`](56e881d]
    [#11975](#11975).

* **Process**
  * Process warning output can be redirected to a file using the
    `--redirect-warnings` command-line argument
    [[`03e89b3ff2`](03e89b3]
    [#10116](#10116).
  * Process warnings may now include additional detail
    [[`dd20e68b0f`](dd20e68]
    [#12725](#12725).

* **REPL**
  * REPL magic mode has been deprecated
    [[`3f27f02da0`](3f27f02]
    [#11599](#11599).

* **Src**
  * `NODE_MODULE_VERSION` has been updated to 57
    (ec7cbaf]
    [#12995](#12995).
  * Add `--pending-deprecation` command-line argument and
    `NODE_PENDING_DEPRECATION` environment variable
    [[`a16b570f8c`](a16b570]
    [#11968](#11968).
  * The `--debug` command-line argument has been deprecated. Note that
    using `--debug` will enable the *new* Inspector-based debug protocol
    as the legacy Debugger protocol previously used by Node.js has been
    removed. [[`010f864426`](010f864]
    [#12949](#12949).
  * Throw when the `-c` and `-e` command-line arguments are used at the same
    time [[`a5f91ab230`](a5f91ab]
    [#11689](#11689).
  * Throw when the `--use-bundled-ca` and `--use-openssl-ca` command-line
    arguments are used at the same time.
    [[`8a7db9d4b5`](8a7db9d]
    [#12087](#12087).

* **Stream**
  * `Stream` now supports `destroy()` and `_destroy()` APIs
    [[`b6e1d22fa6`](b6e1d22]
    [#12925](#12925).
  * `Stream` now supports the `_final()` API
    [[`07c7f198db`](07c7f19]
    [#12828](#12828).

* **TLS**
  * The `rejectUnauthorized` option now defaults to `true`
    [[`348cc80a3c`](348cc80]
    [#5923](#5923).
  * The `tls.createSecurePair()` API now emits a runtime deprecation
    [[`a2ae08999b`](a2ae089]
    [#11349](#11349).
  * A runtime deprecation will now be emitted when `dhparam` is less than
    2048 bits [[`d523eb9c40`](d523eb9]
    [#11447](#11447).

* **URL**
  * The WHATWG URL implementation is now a fully-supported Node.js API
    [[`d080ead0f9`](d080ead]
    [#12710](#12710).

* **Util**
  * `Symbol` keys are now displayed by default when using `util.inspect()`
    [[`5bfd13b81e`](5bfd13b]
    [#9726](#9726).
  * `toJSON` errors will be thrown when formatting `%j`
    [[`455e6f1dd8`](455e6f1]
    [#11708](#11708).
  * Convert `inspect.styles` and `inspect.colors` to prototype-less objects
    [[`aab0d202f8`](aab0d20]
    [#11624](#11624).
  * The new `util.promisify()` API has been added
    [[`99da8e8e02`](99da8e8]
    [#12442](#12442).

* **Zlib**
  * Support `Uint8Array` in Zlib convenience methods
    [[`91383e47fd`](91383e4]
    [#12001](#12001).
  * Zlib errors now use `RangeError` and `TypeError` consistently
    [[`b514bd231e`](b514bd2]
    [#11391](#11391).

jasnell added a commit that referenced this pull request May 30, 2017

2017-05-30, Version 8.0.0 (Current)
* **Async Hooks**
  * The `async_hooks` module has landed in core
    [[`4a7233c178`](4a7233c)]
    [#12892](#12892).

* **Buffer**
  * Using the `--pending-deprecation` flag will cause Node.js to emit a
    deprecation warning when using `new Buffer(num)` or `Buffer(num)`.
    [[`d2d32ea5a2`](d2d32ea)]
    [#11968](#11968).
  * `new Buffer(num)` and `Buffer(num)` will zero-fill new `Buffer` instances
    [[`7eb1b4658e`](7eb1b46)]
    [#12141](#12141).
  * Many `Buffer` methods now accept `Uint8Array` as input
    [[`beca3244e2`](beca324)]
    [#10236](#10236).

* **Child Process**
  * Argument and kill signal validations have been improved
    [[`97a77288ce`](97a7728)]
    [#12348](#12348),
    [[`d75fdd96aa`](d75fdd9)]
    [#10423](#10423).
  * Child Process methods accept `Uint8Array` as input
    [[`627ecee9ed`](627ecee)]
    [#10653](#10653).

* **Console**
  * Error events emitted when using `console` methods are now supressed.
    [[`f18e08d820`](f18e08d)]
    [#9744](#9744).

* **Dependencies**
  * The npm client has been updated to 5.0.0
    [[`3c3b36af0f`](3c3b36a)]
    [#12936](#12936).
  * V8 has been updated to 5.8 with forward ABI stability to 6.0
    [[`60d1aac8d2`](60d1aac)]
    [#12784](#12784).

* **Domains**
  * Native `Promise` instances are now `Domain` aware
    [[`84dabe8373`](84dabe8)]
    [#12489](#12489).

* **Errors**
  * We have started assigning static error codes to errors generated by Node.js.
    This has been done through multiple commits and is still a work in
    progress.

* **File System**
  * The utility class `fs.SyncWriteStream` has been deprecated
    [[`7a55e34ef4`](7a55e34)]
    [#10467](#10467).
  * The deprecated `fs.read()` string interface has been removed
    [[`3c2a9361ff`](3c2a936)]
    [#9683](#9683).

* **HTTP**
  * Improved support for userland implemented Agents
    [[`90403dd1d0`](90403dd)]
    [#11567](#11567).
  * Outgoing Cookie headers are concatenated into a single string
    [[`d3480776c7`](d348077)]
    [#11259](#11259).
  * The `httpResponse.writeHeader()` method has been deprecated
    [[`fb71ba4921`](fb71ba4)]
    [#11355](#11355).
  * New methods for accessing HTTP headers have been added to `OutgoingMessage`
    [[`3e6f1032a4`](3e6f103)]
    [#10805](#10805).

* **Lib**
  * All deprecation messages have been assigned static identifiers
    [[`5de3cf099c`](5de3cf0)]
    [#10116](#10116).
  * The legacy `linkedlist` module has been removed
    [[`84a23391f6`](84a2339)]
    [#12113](#12113).

* **N-API**
  * Experimental support for the new N-API API has been added
    [[`56e881d0b0`](56e881d)]
    [#11975](#11975).

* **Process**
  * Process warning output can be redirected to a file using the
    `--redirect-warnings` command-line argument
    [[`03e89b3ff2`](03e89b3)]
    [#10116](#10116).
  * Process warnings may now include additional detail
    [[`dd20e68b0f`](dd20e68)]
    [#12725](#12725).

* **REPL**
  * REPL magic mode has been deprecated
    [[`3f27f02da0`](3f27f02)]
    [#11599](#11599).

* **Src**
  * `NODE_MODULE_VERSION` has been updated to 57
    (ec7cbaf)]
    [#12995](#12995).
  * Add `--pending-deprecation` command-line argument and
    `NODE_PENDING_DEPRECATION` environment variable
    [[`a16b570f8c`](a16b570)]
    [#11968](#11968).
  * The `--debug` command-line argument has been deprecated. Note that
    using `--debug` will enable the *new* Inspector-based debug protocol
    as the legacy Debugger protocol previously used by Node.js has been
    removed. [[`010f864426`](010f864)]
    [#12949](#12949).
  * Throw when the `-c` and `-e` command-line arguments are used at the same
    time [[`a5f91ab230`](a5f91ab)]
    [#11689](#11689).
  * Throw when the `--use-bundled-ca` and `--use-openssl-ca` command-line
    arguments are used at the same time.
    [[`8a7db9d4b5`](8a7db9d)]
    [#12087](#12087).

* **Stream**
  * `Stream` now supports `destroy()` and `_destroy()` APIs
    [[`b6e1d22fa6`](b6e1d22)]
    [#12925](#12925).
  * `Stream` now supports the `_final()` API
    [[`07c7f198db`](07c7f19)]
    [#12828](#12828).

* **TLS**
  * The `rejectUnauthorized` option now defaults to `true`
    [[`348cc80a3c`](348cc80)]
    [#5923](#5923).
  * The `tls.createSecurePair()` API now emits a runtime deprecation
    [[`a2ae08999b`](a2ae089)]
    [#11349](#11349).
  * A runtime deprecation will now be emitted when `dhparam` is less than
    2048 bits [[`d523eb9c40`](d523eb9)]
    [#11447](#11447).

* **URL**
  * The WHATWG URL implementation is now a fully-supported Node.js API
    [[`d080ead0f9`](d080ead)]
    [#12710](#12710).

* **Util**
  * `Symbol` keys are now displayed by default when using `util.inspect()`
    [[`5bfd13b81e`](5bfd13b)]
    [#9726](#9726).
  * `toJSON` errors will be thrown when formatting `%j`
    [[`455e6f1dd8`](455e6f1)]
    [#11708](#11708).
  * Convert `inspect.styles` and `inspect.colors` to prototype-less objects
    [[`aab0d202f8`](aab0d20)]
    [#11624](#11624).
  * The new `util.promisify()` API has been added
    [[`99da8e8e02`](99da8e8)]
    [#12442](#12442).

* **Zlib**
  * Support `Uint8Array` in Zlib convenience methods
    [[`91383e47fd`](91383e4)]
    [#12001](#12001).
  * Zlib errors now use `RangeError` and `TypeError` consistently
    [[`b514bd231e`](b514bd2)]
    [#11391](#11391).

gibfahn added a commit to gibfahn/node that referenced this pull request Jun 17, 2017

test: introduce `common.crashOnUnhandledRejection`
Ref: nodejs#12442
PR-URL: nodejs#12489
Backport-PR-URL: nodejs#13103
Reviewed-By: Matthew Loring <mattloring@google.com>
Reviewed-By: Julien Gilli <jgilli@nodejs.org>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

gibfahn added a commit that referenced this pull request Jun 20, 2017

test: introduce `common.crashOnUnhandledRejection`
Ref: #12442
PR-URL: #12489
Backport-PR-URL: #13103
Reviewed-By: Matthew Loring <mattloring@google.com>
Reviewed-By: Julien Gilli <jgilli@nodejs.org>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

MylesBorins added a commit that referenced this pull request Jul 11, 2017

test: introduce `common.crashOnUnhandledRejection`
Ref: #12442
PR-URL: #12489
Backport-PR-URL: #13103
Reviewed-By: Matthew Loring <mattloring@google.com>
Reviewed-By: Julien Gilli <jgilli@nodejs.org>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

@MylesBorins MylesBorins referenced this pull request Jul 18, 2017

Merged

v6.11.2 proposal #14356

@ORESoftware

This comment has been minimized.

Show comment
Hide comment
@ORESoftware

ORESoftware Sep 20, 2017

Hey all, I am wondering if anyone on this thread can help answer this question regarding Promises + Domains, thanks

nodejs/help#831

Hey all, I am wondering if anyone on this thread can help answer this question regarding Promises + Domains, thanks

nodejs/help#831

gabrielschulhof added a commit to gabrielschulhof/node that referenced this pull request Mar 12, 2018

2017-05-30, Version 8.0.0 (Current)
* **Async Hooks**
  * The `async_hooks` module has landed in core
    [[`4a7233c178`](nodejs@4a7233c)]
    [#12892](nodejs#12892).

* **Buffer**
  * Using the `--pending-deprecation` flag will cause Node.js to emit a
    deprecation warning when using `new Buffer(num)` or `Buffer(num)`.
    [[`d2d32ea5a2`](nodejs@d2d32ea)]
    [#11968](nodejs#11968).
  * `new Buffer(num)` and `Buffer(num)` will zero-fill new `Buffer` instances
    [[`7eb1b4658e`](nodejs@7eb1b46)]
    [#12141](nodejs#12141).
  * Many `Buffer` methods now accept `Uint8Array` as input
    [[`beca3244e2`](nodejs@beca324)]
    [#10236](nodejs#10236).

* **Child Process**
  * Argument and kill signal validations have been improved
    [[`97a77288ce`](nodejs@97a7728)]
    [#12348](nodejs#12348),
    [[`d75fdd96aa`](nodejs@d75fdd9)]
    [#10423](nodejs#10423).
  * Child Process methods accept `Uint8Array` as input
    [[`627ecee9ed`](nodejs@627ecee)]
    [#10653](nodejs#10653).

* **Console**
  * Error events emitted when using `console` methods are now supressed.
    [[`f18e08d820`](nodejs@f18e08d)]
    [#9744](nodejs#9744).

* **Dependencies**
  * The npm client has been updated to 5.0.0
    [[`3c3b36af0f`](nodejs@3c3b36a)]
    [#12936](nodejs#12936).
  * V8 has been updated to 5.8 with forward ABI stability to 6.0
    [[`60d1aac8d2`](nodejs@60d1aac)]
    [#12784](nodejs#12784).

* **Domains**
  * Native `Promise` instances are now `Domain` aware
    [[`84dabe8373`](nodejs@84dabe8)]
    [#12489](nodejs#12489).

* **Errors**
  * We have started assigning static error codes to errors generated by Node.js.
    This has been done through multiple commits and is still a work in
    progress.

* **File System**
  * The utility class `fs.SyncWriteStream` has been deprecated
    [[`7a55e34ef4`](nodejs@7a55e34)]
    [#10467](nodejs#10467).
  * The deprecated `fs.read()` string interface has been removed
    [[`3c2a9361ff`](nodejs@3c2a936)]
    [#9683](nodejs#9683).

* **HTTP**
  * Improved support for userland implemented Agents
    [[`90403dd1d0`](nodejs@90403dd)]
    [#11567](nodejs#11567).
  * Outgoing Cookie headers are concatenated into a single string
    [[`d3480776c7`](nodejs@d348077)]
    [#11259](nodejs#11259).
  * The `httpResponse.writeHeader()` method has been deprecated
    [[`fb71ba4921`](nodejs@fb71ba4)]
    [#11355](nodejs#11355).
  * New methods for accessing HTTP headers have been added to `OutgoingMessage`
    [[`3e6f1032a4`](nodejs@3e6f103)]
    [#10805](nodejs#10805).

* **Lib**
  * All deprecation messages have been assigned static identifiers
    [[`5de3cf099c`](nodejs@5de3cf0)]
    [#10116](nodejs#10116).
  * The legacy `linkedlist` module has been removed
    [[`84a23391f6`](nodejs@84a2339)]
    [#12113](nodejs#12113).

* **N-API**
  * Experimental support for the new N-API API has been added
    [[`56e881d0b0`](nodejs@56e881d)]
    [#11975](nodejs#11975).

* **Process**
  * Process warning output can be redirected to a file using the
    `--redirect-warnings` command-line argument
    [[`03e89b3ff2`](nodejs@03e89b3)]
    [#10116](nodejs#10116).
  * Process warnings may now include additional detail
    [[`dd20e68b0f`](nodejs@dd20e68)]
    [#12725](nodejs#12725).

* **REPL**
  * REPL magic mode has been deprecated
    [[`3f27f02da0`](nodejs@3f27f02)]
    [#11599](nodejs#11599).

* **Src**
  * `NODE_MODULE_VERSION` has been updated to 57
    (nodejs@ec7cbaf)]
    [#12995](nodejs#12995).
  * Add `--pending-deprecation` command-line argument and
    `NODE_PENDING_DEPRECATION` environment variable
    [[`a16b570f8c`](nodejs@a16b570)]
    [#11968](nodejs#11968).
  * The `--debug` command-line argument has been deprecated. Note that
    using `--debug` will enable the *new* Inspector-based debug protocol
    as the legacy Debugger protocol previously used by Node.js has been
    removed. [[`010f864426`](nodejs@010f864)]
    [#12949](nodejs#12949).
  * Throw when the `-c` and `-e` command-line arguments are used at the same
    time [[`a5f91ab230`](nodejs@a5f91ab)]
    [#11689](nodejs#11689).
  * Throw when the `--use-bundled-ca` and `--use-openssl-ca` command-line
    arguments are used at the same time.
    [[`8a7db9d4b5`](nodejs@8a7db9d)]
    [#12087](nodejs#12087).

* **Stream**
  * `Stream` now supports `destroy()` and `_destroy()` APIs
    [[`b6e1d22fa6`](nodejs@b6e1d22)]
    [#12925](nodejs#12925).
  * `Stream` now supports the `_final()` API
    [[`07c7f198db`](nodejs@07c7f19)]
    [#12828](nodejs#12828).

* **TLS**
  * The `rejectUnauthorized` option now defaults to `true`
    [[`348cc80a3c`](nodejs@348cc80)]
    [#5923](nodejs#5923).
  * The `tls.createSecurePair()` API now emits a runtime deprecation
    [[`a2ae08999b`](nodejs@a2ae089)]
    [#11349](nodejs#11349).
  * A runtime deprecation will now be emitted when `dhparam` is less than
    2048 bits [[`d523eb9c40`](nodejs@d523eb9)]
    [#11447](nodejs#11447).

* **URL**
  * The WHATWG URL implementation is now a fully-supported Node.js API
    [[`d080ead0f9`](nodejs@d080ead)]
    [#12710](nodejs#12710).

* **Util**
  * `Symbol` keys are now displayed by default when using `util.inspect()`
    [[`5bfd13b81e`](nodejs@5bfd13b)]
    [#9726](nodejs#9726).
  * `toJSON` errors will be thrown when formatting `%j`
    [[`455e6f1dd8`](nodejs@455e6f1)]
    [#11708](nodejs#11708).
  * Convert `inspect.styles` and `inspect.colors` to prototype-less objects
    [[`aab0d202f8`](nodejs@aab0d20)]
    [#11624](nodejs#11624).
  * The new `util.promisify()` API has been added
    [[`99da8e8e02`](nodejs@99da8e8)]
    [#12442](nodejs#12442).

* **Zlib**
  * Support `Uint8Array` in Zlib convenience methods
    [[`91383e47fd`](nodejs@91383e4)]
    [#12001](nodejs#12001).
  * Zlib errors now use `RangeError` and `TypeError` consistently
    [[`b514bd231e`](nodejs@b514bd2)]
    [#11391](nodejs#11391).

This applies parts of 43e4efd that are
relevant to N-API.

gabrielschulhof added a commit to gabrielschulhof/node that referenced this pull request Mar 15, 2018

2017-05-30, Version 8.0.0 (Current)
* **Async Hooks**
  * The `async_hooks` module has landed in core
    [[`4a7233c178`](nodejs@4a7233c]
    [#12892](nodejs#12892).

* **Buffer**
  * Using the `--pending-deprecation` flag will cause Node.js to emit a
    deprecation warning when using `new Buffer(num)` or `Buffer(num)`.
    [[`d2d32ea5a2`](nodejs@d2d32ea]
    [#11968](nodejs#11968).
  * `new Buffer(num)` and `Buffer(num)` will zero-fill new `Buffer` instances
    [[`7eb1b4658e`](nodejs@7eb1b46]
    [#12141](nodejs#12141).
  * Many `Buffer` methods now accept `Uint8Array` as input
    [[`beca3244e2`](nodejs@beca324]
    [#10236](nodejs#10236).

* **Child Process**
  * Argument and kill signal validations have been improved
    [[`97a77288ce`](nodejs@97a7728]
    [#12348](nodejs#12348),
    [[`d75fdd96aa`](nodejs@d75fdd9]
    [#10423](nodejs#10423).
  * Child Process methods accept `Uint8Array` as input
    [[`627ecee9ed`](nodejs@627ecee]
    [#10653](nodejs#10653).

* **Console**
  * Error events emitted when using `console` methods are now supressed.
    [[`f18e08d820`](nodejs@f18e08d]
    [#9744](nodejs#9744).

* **Dependencies**
  * The npm client has been updated to 5.0.0
    [[`3c3b36af0f`](nodejs@3c3b36a]
    [#12936](nodejs#12936).
  * V8 has been updated to 5.8 with forward ABI stability to 6.0
    [[`60d1aac8d2`](nodejs@60d1aac]
    [#12784](nodejs#12784).

* **Domains**
  * Native `Promise` instances are now `Domain` aware
    [[`84dabe8373`](nodejs@84dabe8]
    [#12489](nodejs#12489).

* **Errors**
  * We have started assigning static error codes to errors generated by Node.js.
    This has been done through multiple commits and is still a work in
    progress.

* **File System**
  * The utility class `fs.SyncWriteStream` has been deprecated
    [[`7a55e34ef4`](nodejs@7a55e34]
    [#10467](nodejs#10467).
  * The deprecated `fs.read()` string interface has been removed
    [[`3c2a9361ff`](nodejs@3c2a936]
    [#9683](nodejs#9683).

* **HTTP**
  * Improved support for userland implemented Agents
    [[`90403dd1d0`](nodejs@90403dd]
    [#11567](nodejs#11567).
  * Outgoing Cookie headers are concatenated into a single string
    [[`d3480776c7`](nodejs@d348077]
    [#11259](nodejs#11259).
  * The `httpResponse.writeHeader()` method has been deprecated
    [[`fb71ba4921`](nodejs@fb71ba4]
    [#11355](nodejs#11355).
  * New methods for accessing HTTP headers have been added to `OutgoingMessage`
    [[`3e6f1032a4`](nodejs@3e6f103]
    [#10805](nodejs#10805).

* **Lib**
  * All deprecation messages have been assigned static identifiers
    [[`5de3cf099c`](nodejs@5de3cf0]
    [#10116](nodejs#10116).
  * The legacy `linkedlist` module has been removed
    [[`84a23391f6`](nodejs@84a2339]
    [#12113](nodejs#12113).

* **N-API**
  * Experimental support for the new N-API API has been added
    [[`56e881d0b0`](nodejs@56e881d]
    [#11975](nodejs#11975).

* **Process**
  * Process warning output can be redirected to a file using the
    `--redirect-warnings` command-line argument
    [[`03e89b3ff2`](nodejs@03e89b3]
    [#10116](nodejs#10116).
  * Process warnings may now include additional detail
    [[`dd20e68b0f`](nodejs@dd20e68]
    [#12725](nodejs#12725).

* **REPL**
  * REPL magic mode has been deprecated
    [[`3f27f02da0`](nodejs@3f27f02]
    [#11599](nodejs#11599).

* **Src**
  * `NODE_MODULE_VERSION` has been updated to 57
    (nodejs@ec7cbaf]
    [#12995](nodejs#12995).
  * Add `--pending-deprecation` command-line argument and
    `NODE_PENDING_DEPRECATION` environment variable
    [[`a16b570f8c`](nodejs@a16b570]
    [#11968](nodejs#11968).
  * The `--debug` command-line argument has been deprecated. Note that
    using `--debug` will enable the *new* Inspector-based debug protocol
    as the legacy Debugger protocol previously used by Node.js has been
    removed. [[`010f864426`](nodejs@010f864]
    [#12949](nodejs#12949).
  * Throw when the `-c` and `-e` command-line arguments are used at the same
    time [[`a5f91ab230`](nodejs@a5f91ab]
    [#11689](nodejs#11689).
  * Throw when the `--use-bundled-ca` and `--use-openssl-ca` command-line
    arguments are used at the same time.
    [[`8a7db9d4b5`](nodejs@8a7db9d]
    [#12087](nodejs#12087).

* **Stream**
  * `Stream` now supports `destroy()` and `_destroy()` APIs
    [[`b6e1d22fa6`](nodejs@b6e1d22]
    [#12925](nodejs#12925).
  * `Stream` now supports the `_final()` API
    [[`07c7f198db`](nodejs@07c7f19]
    [#12828](nodejs#12828).

* **TLS**
  * The `rejectUnauthorized` option now defaults to `true`
    [[`348cc80a3c`](nodejs@348cc80]
    [#5923](nodejs#5923).
  * The `tls.createSecurePair()` API now emits a runtime deprecation
    [[`a2ae08999b`](nodejs@a2ae089]
    [#11349](nodejs#11349).
  * A runtime deprecation will now be emitted when `dhparam` is less than
    2048 bits [[`d523eb9c40`](nodejs@d523eb9]
    [#11447](nodejs#11447).

* **URL**
  * The WHATWG URL implementation is now a fully-supported Node.js API
    [[`d080ead0f9`](nodejs@d080ead]
    [#12710](nodejs#12710).

* **Util**
  * `Symbol` keys are now displayed by default when using `util.inspect()`
    [[`5bfd13b81e`](nodejs@5bfd13b]
    [#9726](nodejs#9726).
  * `toJSON` errors will be thrown when formatting `%j`
    [[`455e6f1dd8`](nodejs@455e6f1]
    [#11708](nodejs#11708).
  * Convert `inspect.styles` and `inspect.colors` to prototype-less objects
    [[`aab0d202f8`](nodejs@aab0d20]
    [#11624](nodejs#11624).
  * The new `util.promisify()` API has been added
    [[`99da8e8e02`](nodejs@99da8e8]
    [#12442](nodejs#12442).

* **Zlib**
  * Support `Uint8Array` in Zlib convenience methods
    [[`91383e47fd`](nodejs@91383e4]
    [#12001](nodejs#12001).
  * Zlib errors now use `RangeError` and `TypeError` consistently
    [[`b514bd231e`](nodejs@b514bd2]
    [#11391](nodejs#11391).

This applies parts of 43e4efd that are
relevant to N-API.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment