-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
async_hooks: rename currentId to currentAsyncId #13490
Conversation
CI: https://ci.nodejs.org/job/node-test-pull-request/8504/ /cc @nodejs/async_hooks |
doc/api/async_hooks.md
Outdated
@@ -213,7 +213,7 @@ when listening to the hooks. | |||
|
|||
`triggerId` is the `asyncId` of the resource that caused (or "triggered") the | |||
new resource to initialize and that caused `init` to call. This is different | |||
from `async_hooks.currentId()` that only shows *when* a resource was created, | |||
from `async_hooks.currentAsyncId()` that only shows *when* a resource was created, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, the line length is 82 now (may be relevant if we have md linting soon).
doc/api/async_hooks.md
Outdated
@@ -328,7 +328,7 @@ destroy: 9 | |||
destroy: 5 | |||
``` | |||
|
|||
*Note*: As illustrated in the example, `currentId()` and `scope` each specify | |||
*Note*: As illustrated in the example, `currentAsyncId()` and `scope` each specify |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line length is 82.
doc/api/async_hooks.md
Outdated
}); | ||
``` | ||
|
||
It is important to note that the ID returned fom `currentId()` is related to | ||
It is important to note that the ID returned fom `currentAsyncId()` is related to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
line length is 81.
lib/async_hooks.js
Outdated
@@ -477,7 +477,7 @@ function runCallback(cb, asyncId) { | |||
module.exports = { | |||
// Public API | |||
createHook, | |||
currentId, | |||
currentAsyncId, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know we’re okay with some breakage as long as this is fresh & experimental, but maybe
Object.defineProperty(module.exports, 'currentId', { value: currentAsyncId });
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why defineProperty
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because that defaults to non-enumerable, just to avoid a bit of confusion for people inspecting the require('async_hooks')
object :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've created a internalUtil.deprecate
alias.
@@ -600,6 +600,16 @@ The DebugContext will be removed in V8 soon and will not be available in Node | |||
|
|||
*Note*: DebugContext was an experimental API. | |||
|
|||
<a id="DEP0070"></a> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[question] do we deprecate > Stability: 1 - Experimental
API's?
I'm not convinced we need to. Not sure if it's better for users or just noise 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is only noise if they try to use async_hooks.currentId
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about documentation noise, but I yield to @addaleax's opinion that doing it "the usual way" makes sense.
doc/api/deprecations.md
Outdated
`async_hooks.currentId()` was renamed to `async_hooks.currentAsyncId()` for | ||
clarity. | ||
|
||
*Note*: `async_hooks` was an experimental API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we decide to keep this I suggest either /s/was/is/
or *Note*: change was made while `async_hooks` was an experimental API.
lib/async_hooks.js
Outdated
// experimental stage so the alias can be removed at any time, we are just | ||
// being nice :) | ||
Object.defineProperty(module.exports, 'currentId', { | ||
configurable: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should hide it, i.e. { configurable: false, enumerable: false }
so it will work but won't be discoverable by inspection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ack
I'm ±0 on need to deprecate. Not sure if it's better for users or just noise 🤔. |
I'm very much against documenting an API that was never documented because we changed the API. If we are going to alias the method we should print a warning and suggest the better alternative. I don't care if we call it a deprecation or something else. |
FYI: #13483 So I suggest remove the deprecation code, leave just the "niceness" property, and rename this PR (for SEO) |
Yeah no, I’m -1 on that, it makes sense to deprecate things that will be going away at some point. Also, I really don’t know what you mean by “rename this PR” … the current title seems to be accurate? |
Ack. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks much for doing this. Would like to see one more API change along with this.
doc/api/async_hooks.md
Outdated
@@ -29,7 +29,7 @@ Following is a simple overview of the public API. | |||
const async_hooks = require('async_hooks'); | |||
|
|||
// Return the ID of the current execution context. | |||
const cid = async_hooks.currentId(); | |||
const cid = async_hooks.currentAsyncId(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To keep the API uniform I'd like to change triggerId()
to currentTriggerId()
. If that can't happen then I'd say we drop this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something that confuses me about the currentId
renaming is that triggerId
also refers to an asyncId
. So in my mind currentTriggerAsyncId()
is what makes sense. Of cause that is a horribly long name and it doesn't change that currentAsyncId()
isn't really specific. It just says it is an asyncId
that is current, but the same could be said about triggerId
.
My previous understanding was that current
had some special meaning, and a logical renaming of triggerId
would then be triggerAsyncId()
. But your comment invalidates that understanding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AndreasMadsen , maybe async_hooks.currentContext().asyncId
and async_hooks.currentContext().triggerId
more make sense? But it will add a new object..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The most technically correct name for currentId()
would be asyncIdOfCurrentExecutionScope()
.
you're right in that triggerId
is an asyncId
. it's the asyncId
of the resource that is responsible for the callback being called. e.g.
const async_hooks = require('async_hooks');
const net = require('net');
const print = process._rawDebug;
const server = net.createServer(connection => {
print(connection._handle.getAsyncId() === async_hooks.triggerId());
print(server._handle.getAsyncId() === async_hooks.currentId());
server.close();
}).listen(8080, () => net.connect(8080).end());
(unfortunately there's a bug right now which doesn't properly set the triggerId
for the 'connection'
callback)
The currentId
is the server
's asyncId
because the server is responsible for the current execution context. The triggerId
is set to the connection
's asyncId
because the 'connection'
callback would never been called if the new connection hadn't been made.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is currentExecutionAsyncId()
and currentTriggerAsyncId()
then the names? If so, may I suggest we remove the current
part, I think it is implied from a global getter:
executionAsyncId()
triggerAsyncId()
maybe async_hooks.currentContext().asyncId and async_hooks.currentContext().triggerId more make sense? But it will add a new object..
I don't think that solves anything, it just prefixes the names a bit more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AndreasMadsen I'm not picky. If others think the names are more descriptive then I'm fine with them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m not picky either, but I can say that I’ve never regretted using a long identifier if it is just a tiny bit more expressive or easier to understand; muscle memory and/or autocomplete take care of that once you’re used to typing them.
executionAsyncId()
and triggerAsyncId()
sound fine to me, with or without the current
prefix and a slight preference for having the Async
middle bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great. @AndreasMadsen seems like executionAsyncId()
and triggerAsyncId()
are the names to use. Thanks for taking care of this.
How long would you recommend we keep the deprecated API around? I don't think it would be necessary to keep it around once v8.x goes LTS. |
@trevnorris We could probably remove it before that, yes … but why? We can drop it from |
not sure where my mind was. nm me. |
I renamed
Note: Unless it is something very minor I can't spend the time on it, I just don't have the time. Feel free to push to my branch or create a new PR. |
trigger_id_ = AsyncHooksGetTriggerId(isolate); | ||
trigger_async_id_(trigger_async_id) { | ||
if (trigger_async_id_ == -1) | ||
trigger_async_id_ = AsyncHooksGetTriggerAsyncId(isolate); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not related to this PR, but shouldn't this be AsyncHooksGetExecutionAsyncId
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did it this way to match the if (triggerId === undefined) { triggerId = initTriggerId(); …
bit in the JS AsyncResource
class. AsyncHooksGetTriggerAsyncId()
uses env->get_init_trigger_id()
which defaults to env->current_async_id()
, and that also matches what initTriggerId()
in JS does, so if anything needs to be changed here it should also be changed in JS.
This does look correct to me, though… @trevnorris ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, right. It is the AsyncHooksGetTriggerAsyncId
implementation that is wrong then, it should return async_uid_fields[kCurrentTriggerId]
not async_uid_fields[kInitTriggerId]
.
The actual behavior in AsyncResource
is fine.
One of the windows runs went pathological, so I killed it:
/cc @nodejs/build (maybe it needs cleanup) |
A new test landed in master, the CI auto rebased and that caused some issues. |
One test failure on arm-ubuntu:
I don't think it is related. |
@refack @addaleax @trevnorris please review again. I keep having to fix rebase conflicts, so I would like to land this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
(rubber stamp completeness)
Just so you know, we have published the docs: https://nodejs.org/api/async_hooks.html |
It was true at the time :). With the deprecated aliases, I don't think it is an issue. |
All these test failures make me nervous. I think they are all unrelated, but could one of you give me a second opinion. |
Looks like ARM is online again. Rerunning CI: https://ci.nodejs.org/job/node-test-pull-request/8646/ |
only one failure (#13577), and it is not related. I will merge this. |
landed in de762b7 |
currentId is renamed to executionAsyncId triggerId is renamed to triggerAsyncId AsyncResource.triggerId is renamed to AsyncResource.triggerAsyncId AsyncHooksGetCurrentId is renamed to AsyncHooksGetExecutionAsyncId AsyncHooksGetTriggerId is renamed to AsyncHooksGetTriggerAsyncId PR-URL: #13490 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Trevor Norris <[email protected]>
currentId is renamed to executionAsyncId triggerId is renamed to triggerAsyncId AsyncResource.triggerId is renamed to AsyncResource.triggerAsyncId AsyncHooksGetCurrentId is renamed to AsyncHooksGetExecutionAsyncId AsyncHooksGetTriggerId is renamed to AsyncHooksGetTriggerAsyncId PR-URL: #13490 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Trevor Norris <[email protected]>
currentId is renamed to executionAsyncId triggerId is renamed to triggerAsyncId AsyncResource.triggerId is renamed to AsyncResource.triggerAsyncId AsyncHooksGetCurrentId is renamed to AsyncHooksGetExecutionAsyncId AsyncHooksGetTriggerId is renamed to AsyncHooksGetTriggerAsyncId PR-URL: #13490 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Trevor Norris <[email protected]>
currentId is renamed to executionAsyncId triggerId is renamed to triggerAsyncId AsyncResource.triggerId is renamed to AsyncResource.triggerAsyncId AsyncHooksGetCurrentId is renamed to AsyncHooksGetExecutionAsyncId AsyncHooksGetTriggerId is renamed to AsyncHooksGetTriggerAsyncId PR-URL: #13490 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Trevor Norris <[email protected]>
currentId is renamed to executionAsyncId triggerId is renamed to triggerAsyncId AsyncResource.triggerId is renamed to AsyncResource.triggerAsyncId AsyncHooksGetCurrentId is renamed to AsyncHooksGetExecutionAsyncId AsyncHooksGetTriggerId is renamed to AsyncHooksGetTriggerAsyncId PR-URL: #13490 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Trevor Norris <[email protected]>
currentId is renamed to executionAsyncId triggerId is renamed to triggerAsyncId AsyncResource.triggerId is renamed to AsyncResource.triggerAsyncId AsyncHooksGetCurrentId is renamed to AsyncHooksGetExecutionAsyncId AsyncHooksGetTriggerId is renamed to AsyncHooksGetTriggerAsyncId PR-URL: #13490 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Trevor Norris <[email protected]>
- currentId() => executionAsyncId() - triggerId() => triggerAsyncId() see nodejs/node#13490
…telyTyped#18530) - currentId() => executionAsyncId() - triggerId() => triggerAsyncId() see nodejs/node#13490
- currentId() => executionAsyncId() - triggerId() => triggerAsyncId() see nodejs/node#13490
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
async_hooks
Rename rename
async_hooks.currentId()
toasync_hooks.currentAsyncId()
as requested by @trevnorris. I just did a search and replace, it appears to work.Since
async_hooks
is an experimental API and we actually haven't published the docs, then I think this is asemver-minor
.To be completely fair to the "
make -j4 test
passes" I actually couldn't run it all, I'm getting this error:I don't think it is related. I'm going to see what the CI says.