Durable use cache: fix runtime env var mutation

[mischnic]

Problem

1. Next computes the warmup cache key while SOME_ENV_VAR is unset.
2. Rendering ends up setting SOME_ENV_VAR.
3. Final prerender expects the cache entry to exist, but the env var changed, so the key changed and it's a miss.
4. Unexpected miss and bailout.

This lead to

Error: Route "foo": Unexpected cache miss after cache warming phase during prerendering. This is
likely caused by non-deterministic arguments that differ between the cache warming phase and the
final prerender phase (e.g. unstable array order). Ensure that arguments passed to cached functions
are deterministic.

Error: Route "foo": Next.js encountered uncached or runtime data during
prerendering.

Solution

Instead, snapshot the env vars once at module evaluation time of the use cache function. This ensures that the cache key doesn't change over time. This is also how it worked thus far (with deployment id as the cache key): changing the env var over the lifetime of the process didn't lead to a reexecution of the use cache function

RDC already stores cache entries generated in the previous phase (be it during next build multi-phase rendering, or from prerender->resuming at runtime). Root params are already excluded from the cache keys when storing in RDC. Also exclude the env var hash bit, to conform to this system of preventing tearing (at the cost of potential staleness).

[mischnic]

• Durable use cache: fix runtime env var mutation #98558 👈 (View in Graphite)
• Durable use cache: optimize env var existence checks #98504
• canary

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

Tests Passed

Commit: cc7aa3a

[gnoff]

I don't love these expect.not.toContain because if we ever change the error text the test stops offering protection. I think we need to snapshot something here but do it in a way that doesn't churn too much. Or we need a debug that prints an affirmation that we didn't get this error or something

[mischnic]

Yeah, true. I could also assert Error:, that is hopefully stable...