Enforcing cache invalidation to enable non zero stale time

[rajatrawataku1]

I’m working on setting a non-zero stale time for all of our queries — for example, 30 seconds (currently, it’s set to zero for all of them). To make this effective, we’ll need to require developers to write invalidation logic after a mutation if the mutation affects any queries.

Now, my question is:
Should we set the stale time to Infinity in the development environment so that developers are forced to write invalidation logic when creating new features? We’re concerned that setting it to Infinity (instead of 30 seconds) might:

1. Hide potential issues that would otherwise surface during development. For example - un necessary network calls from a component won't be seen during development.
2. Prevent developers from observing the actual behavior that would occur in production.

If we keep the stale time in development the same as production (i.e., 30 seconds), there's a risk that developers won’t notice stale data issues, especially if the action they’re performing naturally takes more than 30 seconds. In such cases, the cache would already be considered stale, and queries would re-fetch automatically — hiding the fact that the proper invalidation logic is missing.

[TkDodo]

sure, there’s no harm in that. I personally like automatic revalidation because it will scale a bit better when you add queries later that you need to add to your fine grained invalidation everywhere:

• https://tkdodo.eu/blog/automatic-query-invalidation-after-mutations