René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Revisit the AsyncLocalStorage onPropagate option","articleBody":"The `onPropagate` option was landed as experimental in v19.2... I'd like to propose that we revisit that and take a different approach.\r\n\r\nhttps://nodejs.org/dist/latest-v19.x/docs/api/async_context.html#new-asynclocalstorageoptions\r\n\r\nAs background, `onPropagate` attaches a callback function to the `AsyncLocalStorage` instance that is invoked whenever a new `AsyncResource` is created. This is problematic primarily because it incurs a significant additional performance overhead and assumes a model that is based on the underlying async_hooks API model (which I think there's consensus we want to move away from https://github.com/nodejs/node/issues/46265).\r\n\r\nAlternatively, I'd like to propose a \"tag' model like in the following example:\r\n\r\n```js\r\n// Defines the ALS instance such that a matching tag must be\r\n// passed in to `getStore()` to successfully retrieve the store.\r\nconst als = new AsyncLocalStorage({ tag: 'foo' });\r\n\r\nconsole.log(als.run(123, () => als.getStore('foo')); // 123\r\nconsole.log(als.run(321, () => als.getStore()); // undefined, doesn't match\r\nconsole.log(als.run(321, () => als.getStore('bar')); // undefined, doesn't match\r\n```\r\n\r\nThe `tag` here effectively becomes a component of the storage key. This is much more efficient design that will not incur a significant additional performance penalty.\r\n\r\n/cc @legendecas @littledan @nodejs/async_hooks ","author":{"url":"https://github.com/jasnell","@type":"Person","name":"jasnell"},"datePublished":"2023-01-26T19:09:49Z","url":"https://github.com/nodejs/node/issues/46374"}