use cache after connection

[mblandr]

https://nextjs.org/docs/app/api-reference/directives/use-cache-remote
Doc says:
When Next.js encounters certain APIs like connection(), cookies(), or headers(), the context becomes "dynamic". In a dynamic context:

Regular use cache stops working - it won't cache anything
but here is changed sample from documentation on simple page

import { setTimeout } from 'node:timers/promises';
import { cacheLife, cacheTag } from 'next/cache';
import { connection } from 'next/server';
import { Suspense } from 'react';

export default async function Page() {
	return (
		<Suspense fallback={<div>Loading price...</div>}>
			<ProductPrice productId="123123" />
		</Suspense>
	);
}

async function ProductPrice({ productId }: { productId: string }) {
	// Calling connection() makes this component dynamic, preventing
	// it from being included in the static shell. This ensures the price
	// is always fetched at request time.
	await connection();

	// Now we can cache the price in a remote cache handler.
	// Regular 'use cache' would NOT work here because we're in a dynamic context.
	await setTimeout(2000);
	const price = await getProductPrice(productId);

	return <div>Price: ${price}</div>;
}

async function getProductPrice(productId: string) {
	'use cache';
	cacheTag(`product-price-${productId}`);
	cacheLife({ expire: 50 }); // 1 hour
	console.log('getProductPrice called');
	// This database query is cached and shared across all users
	return +productId * Math.random() * 1000;
}

and I see that use cache works fine end expires correctly.
await cookies()
instead of
await connection();
works too
What do I miss?

[yassine-krichen]

You are not missing anything, you have actually discovered a nuance where the documentation simplifies the reality to encourage "correct" architectural patterns, even though the underlying mechanics are more flexible.

Here is the breakdown of why your code works, why the docs say it shouldn't, and the subtle difference between use cache and use cache: remote.

1. Why your code works

The directive 'use cache' creates a function-level cache boundary.

When you put 'use cache' inside getProductPrice, you are telling Next.js: "Treat this function's inputs (arguments) as the cache key and its output as the cache value."

Even though the Parent Component (Page or ProductPrice) is dynamic (due to await connection() or cookies()), the Child Function (getProductPrice) is isolated.

• The Page: Runs on every request (Dynamic).

• The Function: Checks the Data Cache. If the key (product-price-123) exists and is fresh, it returns the value without executing the function body.

Therefore, the dynamic nature of the parent does not "infect" the cached function, provided the cached function itself does not try to access dynamic data (like reading headers inside the cached scope).

2. What the Docs mean by "Stops Working"

When the documentation says:

"In a dynamic context: Regular use cache stops working - it won't cache anything"

They are simplifying the behavior of Implicit Caching vs. Explicit Directives.

• The "Old" World (Standard Fetch): If a page became dynamic (e.g., using cookies()), standard fetch calls without specific cache tags would default to { cache: 'no-store' }. They would stop caching.

• The "New" World (use cache directive): This directive is powerful. It forces a cache entry into the cache handler regardless of the parent context.

However, the documentation is likely warning you about Static Generation (Build Time).

• Regular use cache: Ideally runs at build time to prune the code from the runtime bundle (prerendering).

• Dynamic Context: If the parent is dynamic, use cache cannot run at build time. It forces the caching to happen at Runtime.

In short: Your code works, but it has shifted from "Prerendered Cache" (Build time) to "Just-in-Time Cache" (Runtime), which is exactly what use cache: remote is explicitly designed for.

3. The Difference: use cache vs. use cache: remote

Since both currently seem to do the same thing in a dynamic component (cache at runtime), why does remote exist?

A. Semantics and Guardrails

'use cache: remote' is an explicit signal to the developer and the compiler: "I know this cannot be prerendered. I expect this to hit a remote cache (like Redis) at runtime."

If you use standard 'use cache', Next.js wants to prerender it. If it finds it can't (because it's nested deep in a dynamic tree), it falls back to runtime caching (which is what you are seeing). Using remote removes the ambiguity.

B. Future Optimization

Next.js is moving towards an infrastructure where:

• use cache: Might be optimized for the edge or static storage (blobs).

• use cache: remote: Is optimized for high-speed, low-latency key-value stores (like Redis) specifically for shared data that fluctuates frequently.

C. Input Constraints

• use cache: Extremely strict. It expects purely serializable arguments.

• use cache: remote: May eventually allow looser constraints or different timeout behaviors suited for request-time fetching.

[engripaye]

---

✅ Valid Answer

The key detail is this:

Dynamic APIs (like cookies(), connection(), headers()) don’t disable use cache.
They only disable static deduping and static optimization.

This is the part that’s easy to misunderstand.

---

✔️ What actually happens under the hood

When you call:

await connection();

or

await cookies();

Next.js marks the route as dynamic, meaning:

• No static prerendering
• No static shell in the HTML
• No stale-while-revalidate static caching
• No build-time deduping

But it does NOT stop the server-side cache handlers (use cache, cacheTag, cacheLife) from working.

Those APIs are remote cache APIs, not static cache APIs.

They continue to work because they:

• run at request time
• store values inside the Next.js global runtime cache (or your remote cache adapter)
• are independent of static optimization

---

✔️ Why your example still works

Even though the route is dynamic:

await connection(); // OR await cookies()

this block:

'use cache';
cacheTag(`product-price-${productId}`);
cacheLife({ expire: 50 });

creates a runtime-level memoized cache entry, not a static one.

So caching still works exactly as expected:

• first request → executes function
• subsequent requests → served from the runtime cache
• expires after the TTL
• works across all users
• works even in dynamic routes
• works during development and production

This is intended behavior.

---

✔️ What doesn’t work in dynamic context

The docs refer specifically to THIS type of caching:

❌ static deduping of fetch()

❌ route segment prerender caching

❌ static RSC memoization during build

❌ auto-suspense static shells

Those optimizations depend on the route being static.
Once you call cookies(), headers(), or connection(), those optimizations are disabled.

---

✔️ Summary (the short version)

• use cache still works in dynamic routes — this is expected.
• What doesn’t work is static-level caching and deduping.
• use cache, cacheTag, and cacheLife use the remote cache, which is independent of static behavior.
• That's why your example behaves correctly.

---