| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
The connection-callback comment claims triggerAsyncId() returns the asyncId of "conn". It actually returns the server's own triggerAsyncId, because the callback runs in the execution scope of the server's MakeCallback() — as the sibling executionAsyncId() example already explains. Mirror that comment. Fixes: nodejs#21078 Signed-off-by: Julian Soreavis <julian.soreavis@gmail.com>
| Back | FazBrowse Home | New Git URL |
The triggerAsyncId() example's connection-callback comment claims the return value "is the asyncId of conn". It isn't, and never was: the callback runs in the execution scope of the server's MakeCallback(), so triggerAsyncId() returns the server's own triggerAsyncId — measured by the reporter on v8/v10 in #21078 and re-verified on current main (server asyncId 2/trigger 1, conn asyncId 10: the callback sees triggerAsyncId() === 1, executionAsyncId() === 2). The sibling executionAsyncId() example above has stated the correct pattern since the original async_hooks docs (#13287); this mirrors its comment. In #21078, @apapirovski noted the docs don't match reality and @addaleax confirmed "a documentation change would definitely suffice".
Scoped to the inline comment — the only text that contradicts reality. The section's definition line and the .listen() comment are correct and untouched; verified against src/connection_wrap.cc (OnConnection fires the server wrap's MakeCallback) and src/async_wrap.cc/src/api/callback.cc (push_async_context receives the server's own asyncId/triggerAsyncId pair). Comment-only precedent in this file: #42499.
I used an AI assistant while researching and drafting this change; I've verified the behavior and the wording against the source and a live repro myself and take full responsibility for it.
Fixes: #21078