Open joshkel opened 4 months ago
Yeah, hapi would probably need to expose this. But we can't call any AsyncLocalStorage
logic, since this needs to be exclusively managed by the user, as there is only one store.
But even if we do this, there would be pitfalls, eg. when a request is modified outside the regular processing promise chain, like on a disconnect. As such, I would not think that it is safe to use AsyncLocalStorage
to manage state across the request life-cycle.
Even if the above can be solved, I don't think it makes sense to support this in hapi based on your "it would be nice" use-case. Hapi already has the request
and response
objects that can be used to manage state.
Thanks for the quick reply, @kanongil.
I'm not sure what you mean by "there is only one store" - calling code can create multiple AsyncLocalStorage
instances as needed.
request
and response
are very good for Hapi-aware code, but for other code I'm trying to integrate, adapting it to use an
AsyncLocalStorage
singleton seems much easier than passing down parts of Hapi requests through multiple layers. (Maybe this does fall under the bucket of "it would be nice.")
And some third-party APIs that I looked at, like parts of OTel or parts of Sentry, seem very hard to make work without some way of wrapping the request handling as a callback. (Presumably because they're using AsyncLocalStorage
or similar under the hood.)
Or, at least, most of the request - I don't think that special cases like request disconnects would pose a problem for most of these purposes.
I appreciate the the consideration, and if this doesn't fit Hapi's design or priorities, I understand and don't want to take more of your time. Thanks again.
@joshkel it was talked about in the slack recently if you're interested in an implementation:
Runtime
Node.js
Runtime version
18.17.1
Module version
21.3.10
Used with
Hapi application
Any other relevant information
No response
What problem are you trying to solve?
I'm looking into using AsyncLocalStorage to make certain values accessible throughout my application logic, without explicitly passing it as a parameter everywhere.
As far as I can tell, this is a poor fit for Hapi: Hapi lifecycle methods and plugins offer extension points, for invoking arbitrary logic at different points in the application. However, AsyncLocalStorage wants to be invoked with an asynchronous callback, so it can see the start-to-finish execution of amethod; I can't find a way for a Hapi plugin to wrap a request or handler method start-to-finish.
Similar questions come up with instrumentation and monitoring frameworks such as Sentry or OpenTelemetry; OpenTelemetry's Hapi instrumentation currently uses complex runtime patching to accomplish its goals.
Do you have a new or modified API suggestion to solve the problem?
Hapi could offer a new lifecycle method / extension point that's invoked with a callback, so it can see the entire method start to finish.
Alternatively, Hapi could add explicit support for one or more AsyncLocalStorage instances.