Does use cache make the build non-deterministic?

[charshin]

Summary

Normally, I would expect my build to be deterministic, meaning if it succeeds the first time, it will always succeed especially across multiple deployments.
However, if you have a function that needs network request to external API or even your own backend, and you use use cache to include it in the pre-rendered static shell. Then, next build can potentially fail if the API is down, in a sense, your build success now is contingent/dependent upon external factor. In other words, my deployment can succeed today but the same deployment can fail sometime later.
Am I understanding it correctly or missing something?

Additional information

No response

Example

No response

[icyJoseph]

The reason why certain operations, dynamic data access or Math.random, etc, suspend by default (require a fallback) is exactly what you describe. They are all truly asynchronous work, (in this context not limited to JS async mechanics necessarily), they take an indeterminate time to complete, under which we consider them pending, and might resolve or reject, and/or yield different results every time you call them.

What use cache allows you to do at build time, is to take a snapshot in time of these operations at-the-time-of-build, by actually running them, and paying upfront the time cost, and storing that result into the static shell (even Math.random). Further more you assign a cacheLife (explicitly or implicitly) stating for how long this is an acceptable snapshot of the data.

The key thing here is, whether an operation at build time rejects or not, and if that changes the inherent deterministic nature of the your applications build step, is not given by use cache - the directive is not what makes builds non-deterministic - that's just what working with asynchronous operations has in store for you.

If you need builds to be “always green” even when dependencies are flaky: don’t make the build depend on those dependencies. Defer to request time with and/or render a fallback/error state.

If you’re okay with “snapshot what we can at prerender time”: use use cache, set an appropriate cacheLife, and code defensively (try/catch or error boundaries) so an outage doesn’t automatically become a failed build.

With use cache though you can do interesting things like (and though you could also with ISR, that still made you opt-in the entire route into static, whereas Cache Components lets you have static and dynamic parts):

If you build today with a cache life of "hours" assigned to some data, and then wait a few hours to start the server, then upon start, you'll see stale data ("hours" expires after 1 day, but does stale-while-revalidate after 1 hour) - and the shell will be patched.

If the process that generates this data fails, you can still assign a shorter cache life to that (but not too short).

If your API service is down, then you might choose to act on that in the code, and render a different branch, under use cache still, that renders a message: API is down - we're looking into it.

Then it really depends on the business case, if your service is truly down, then eventually all users, regardless of deployment instance, will start to see the error message, and depending on your revalidate/expire timings, the server will try to regenerate this UI, hopefully without overloading a fallen service.