feat(core): Add async context abstraction#7753
Conversation
|
Also, on the naming front, would it be better if |
|
Can we make function runWithHub<T, A extends unknown[]>(callback: (hub: Hub, ...args: A) => T, ...args: A): T; |
I like this - it's more backwards compat as well. @lforst will be a fan :) |
indeed <3 |
Yeah possibly, and then just |
|
This is safer since we know all the args will be of the same type: function runWithAsyncContext<T, A>(callback: (hub: Hub, ...args: A[]) => T, ...args: A[]): T; |
How about the following? I think this should work (at least as the user-facing type - internally we may need some casts): function runWithAsyncContext<C extends (hub: Hub, ...args: any[]) => any>(callback: C): ReturnType<C>; |
We need to pass the callback args as parameters to the top level function so we can use them in our I tried this PR in its current state and replaced some In SDKs where these additional arguments are not required or a bit smelly, we could re-export |
…mfish/sentry-javascript into async-context/add-abstraction
Adds
AsyncContextStrategyabstraction to core.I still have some major concerns over whether this should be in
@sentry/coreat all as it feels messy.To cater for Node.js, the
runWithHubsignature in this PR does not actually suffice and would need to be something like below to cater for the existing domain code.sentry-javascript/packages/node/src/handlers.ts
Lines 184 to 188 in a0e9489
EventEmitterdoesn't exist outside of Node.js, so we'd need to create some matching types or do someanyorunknownfudging.If/when the async context proposal lands and
runWithHubgets exported from@sentry/browserwe almost certainly wont want to export this node specific signature.If we export platform specific
getCurrentHub()andrunWithHub()from their respective packages, no changes are required in core apart from removing the existing platform specific code and the platform specific packages get one additional export (ie.runWithHub).