-
Notifications
You must be signed in to change notification settings - Fork 29.9k
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: destroy emitted more than once for an asyncId #26961
Comments
@nodejs/async_hooks |
I am able to reproduce the error and it seems this always fails with the identical |
I expect this is related to reusing By increasing |
I think destroy gets once triggered via |
Seems #25094 didn't fix this but the behaviour is different. I think the problem now is that |
Fix some issues introduced/not fixed via #25094: * Init hook is not emitted for a reused HTTPParser * HTTPParser was still used as resource in init hook * type used in init hook was always HTTPINCOMINGMESSAGE even for client requests * some tests have not been adapted to new resource names With this change the async hooks init event is emitted during a call to Initialize() as the type and resource object is available at this time. As a result Initialize() must be called now which could be seen as breaking change even HTTPParser is not part of documented API. It was needed to put the ClientRequest instance into a wrapper object instead passing it directly as async resource otherwise test-domain-multi fails. I think this is because adding an EventEmitter to a Domain adds a property 'domain' and the presence of this changes the context propagation in domains. Besides that tests still refering to resource HTTPParser have been updated/improved. Fixes: #27467 Fixes: #26961 Refs: #25094 PR-URL: #27477 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rich Trott <[email protected]>
@mcollina is the person who thought #25094 should not land on v10.x. Pinging them to make sure that's still their view. If you can find a way to fix it that avoids whatever their concerns about landing that PR on v10.x were, then yes! |
(Also, thanks for being on top of this stuff!) |
Avoid that destroy hook is invoked twice - once via `Parser::Free()` and once again via `Parser::Reinitialize()` by clearing the async_id in `EmitDestroy()`. Partial backport of nodejs#27477, a full backport would require also nodejs#25094 which has a dont-land-on-v10.x label on it. Fixes: nodejs#26961
Avoid that destroy hook is invoked twice - once via `Parser::Free()` and once again via `Parser::Reinitialize()` by clearing the async_id in `EmitDestroy()`. Partial backport of #27477, a full backport would require also #25094 which has a dont-land-on-v10.x label on it. Fixes: #26961 Backport-PR-URL: #27986 PR-URL: #27477 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Avoid that destroy hook is invoked twice - once via `Parser::Free()` and once again via `Parser::Reinitialize()` by clearing the async_id in `EmitDestroy()`. Partial backport of #27477, a full backport would require also #25094 which has a dont-land-on-v10.x label on it. Fixes: #26961 Backport-PR-URL: #27986 PR-URL: #27477 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rich Trott <[email protected]>
This code shows
destroy
emitting twice for a singleasyncId
. (You may need to run it more than once to see the error and/or increase the value ofN
in the code, but it repros most of the time for me.)The text was updated successfully, but these errors were encountered: