fix: Memoize AsyncLocalStorage instance

[lforst]

Attempts to fix the memory leak reported in #8829 by memoizing the AsyncLocalStorage instance we create when setting the async context strategy.

Note for reviewers: Can you think of any problems this may cause?

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser (incl. Tracing, Replay) - Webpack (gzipped)	75.16 KB (+0.41% 🔺)
@sentry/browser (incl. Tracing) - Webpack (gzipped)	31.17 KB (+0.2% 🔺)
@sentry/browser - Webpack (gzipped)	21.85 KB (+0.19% 🔺)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (gzipped)	69.73 KB (+0.27% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (gzipped)	28.18 KB (+0.1% 🔺)
@sentry/browser - ES6 CDN Bundle (gzipped)	20.18 KB (+0.05% 🔺)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (minified & uncompressed)	219.89 KB (+0.38% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (minified & uncompressed)	84.78 KB (+0.13% 🔺)
@sentry/browser - ES6 CDN Bundle (minified & uncompressed)	59.86 KB (+0.04% 🔺)
@sentry/browser (incl. Tracing) - ES5 CDN Bundle (gzipped)	31.04 KB (+0.09% 🔺)
@sentry/react (incl. Tracing, Replay) - Webpack (gzipped)	75.18 KB (+15.57% 🔺)
@sentry/react - Webpack (gzipped)	21.88 KB (+0.18% 🔺)
@sentry/nextjs Client (incl. Tracing, Replay) - Webpack (gzipped)	92.97 KB (+0.35% 🔺)
@sentry/nextjs Client - Webpack (gzipped)	50.7 KB (+0.19% 🔺)

[Lms24]

Hmm I'm not sure but wouldn't this mean we potentially reuse the same asyncLocalStorage instance across multiple requests which we actually want to isolate? Don't have a ton of context around ALS so not sure if this concern makes sense

[lforst]

Hmm I'm not sure but wouldn't this mean we potentially reuse the same asyncLocalStorage instance across multiple requests

Well yes, but that is theoretically not an issue. What matters is that localStorage.run(obj) is called for each separate isolate. To give you some insight, whenever you run localStorage.run(obj) you set what localStorage.get() returns in that particular async context. It shouldn't matter that it's the same AsyncLocalStorage instance.

I am trying to come up with a case where we might run into problems here, but I am struggling. I guess the baseline where this potentially messes up always involves calling Sentry.init() multiple times (which is already kinda funky and not supported) and then doing weird stuff with hubs.

[Lms24]

Thanks for explaining, this makes sense to me now! I'd say we give it a try and if the issue author is comfortable with trying this out locally first, it'd be even better.

[lforst]

TIL the leak is likely because AsyncLocalStorage objects need to be disabled in order to be garbage collected: docs

[mydea]

[timfish]

Wouldn't this stop us or customers from overriding the async strategy after it's been set by @sentry/node?

[timfish]

Wouldn't this stop us or customers from overriding the async strategy after it's been set by @sentry/node?

No sorry, I misundersttod the changes!