Currently the cache components feature in Next.js prevents us from using any random value APIs like: - `Date.now` - `performance.now` - `Math.random` - `crypto.*` We tried resolving this by patching several span methods, but then we have plenty of other instances where we use those APIs, like in trace propagation, timestamp generation for logs, and more. Running around and patching them one by one in the Next.js SDK isn't a viable solution since most of those functionalities are strictly internal and cannot be patched from the outside, and adding escape hatches for each of them is not maintainable. So I'm testing out the other way around, by hunting those APIs down and wrapping them with a safe runner that acts as an escape hatch. Some of the Vercel engineers suggested doing that, but we need to do it for ~almost every call~ (see Josh [comment](getsentry#18700 (comment)) below). The idea is an SDK can "turn on" the safe runner by injecting a global function that executes a callback and returns its results. I ### How does this fix it for Next.js? The Next.js SDK case, a safe runner would be an `AsyncLocalStorage` snapshot which is captured at the server runtime init, way before any rendering is done. ```ts const sym = Symbol.for('__SENTRY_SAFE_RANDOM_ID_WRAPPER__'); const globalWithSymbol: typeof GLOBAL_OBJ & { [sym]?: SafeRandomContextRunner } = GLOBAL_OBJ; globalWithSymbol[sym] = AsyncLocalStorage.snapshot(); // core SDK then offers a fn to run any random gen function export function withRandomSafeContext<T>(cb: () => T): T { // Looks for the global symbol and if it is set it uses the runner // otherwise just runs the callback normally. } ``` I kept the API internal as much as possible to avoid users messing up with it, but the `@sentry/opentelemetry` SDK also needed this functionality so I exported the API with `_INTERNAL` prefix as we already do. --- I tested this in a simple Next.js app and it no longer errors out, and all current tests pass. I still need to take a look at the traces and see how would they look in cached component cases. Charly is already working on this and may have a proper solution, but I thought to just see if we can ship a stopgap until then. On the bright side, this seems to fix it as well for Webpack. closes getsentry#18392 closes getsentry#18340

Uh oh!

Support cacheComponents on webpack #18340

Description

Metadata

Metadata

Assignees

Labels

Fields

Projects

Milestone

Relationships

Development

Issue actions

Support `cacheComponents` on webpack #18340