[PR #294] [MERGED] Fix unstable_cache serving stale entries and incorrect revalidate default #452

New issue

Closed

opened 2026-05-06 12:39:52 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-06 12:39:52 +02:00

Owner

📋 Pull Request Information

Original PR: https://github.com/cloudflare/vinext/pull/294
Author: @southpolesteve
Created: 3/6/2026
Status: ✅ Merged
Merged: 3/6/2026
Merged by: @southpolesteve

Base: main ← Head: fix/unstable-cache-staleness-and-revalidate

📝 Commits (2)

872c2f6 Fix unstable_cache serving stale entries and incorrect revalidate default
1eb8249 Update IncrementalCacheValue.revalidate type in next-shims.d.ts

📊 Changes

3 files changed (+89 additions, -5 deletions)

View changed files

📝 packages/vinext/src/shims/cache.ts (+9 -4)
📝 packages/vinext/src/shims/next-shims.d.ts (+1 -1)
📝 tests/shims.test.ts (+79 -0)

📄 Description

Summary

Stale entries served indefinitely: unstable_cache was not checking cacheState when reading from the cache, so time-expired entries were served forever instead of triggering a re-fetch. Added a cacheState !== "stale" check to match the pattern used in the "use cache" runtime.
Incorrect default for revalidate: When no revalidate option was provided, the cached entry was stored with revalidate: 0. This is semantically wrong since 0 means "revalidate immediately" in Next.js cache semantics. Changed the default to false, which means "cache indefinitely" (no time-based expiry), matching Next.js behavior for unstable_cache without an explicit revalidate.
Widened CachedFetchValue.revalidate type from number to number | false to reflect the valid states.

Tests

Added 2 new tests:

unstable_cache re-fetches when entry is stale (time-expired) — verifies stale entries trigger re-computation
unstable_cache with no revalidate option caches indefinitely — verifies revalidateAt is null (not 0) when no revalidate is specified

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/cloudflare/vinext/pull/294 **Author:** [@southpolesteve](https://github.com/southpolesteve) **Created:** 3/6/2026 **Status:** ✅ Merged **Merged:** 3/6/2026 **Merged by:** [@southpolesteve](https://github.com/southpolesteve) **Base:** `main` ← **Head:** `fix/unstable-cache-staleness-and-revalidate` --- ### 📝 Commits (2) - [`872c2f6`](https://github.com/cloudflare/vinext/commit/872c2f6780a508c08e35ac070dd5034f1c23ce43) Fix unstable_cache serving stale entries and incorrect revalidate default - [`1eb8249`](https://github.com/cloudflare/vinext/commit/1eb8249caaa2dab9f870cfac9aa3e14ba3782913) Update IncrementalCacheValue.revalidate type in next-shims.d.ts ### 📊 Changes **3 files changed** (+89 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `packages/vinext/src/shims/cache.ts` (+9 -4) 📝 `packages/vinext/src/shims/next-shims.d.ts` (+1 -1) 📝 `tests/shims.test.ts` (+79 -0) </details> ### 📄 Description ## Summary - **Stale entries served indefinitely:** `unstable_cache` was not checking `cacheState` when reading from the cache, so time-expired entries were served forever instead of triggering a re-fetch. Added a `cacheState !== "stale"` check to match the pattern used in the `"use cache"` runtime. - **Incorrect default for `revalidate`:** When no `revalidate` option was provided, the cached entry was stored with `revalidate: 0`. This is semantically wrong since `0` means "revalidate immediately" in Next.js cache semantics. Changed the default to `false`, which means "cache indefinitely" (no time-based expiry), matching Next.js behavior for `unstable_cache` without an explicit revalidate. - Widened `CachedFetchValue.revalidate` type from `number` to `number | false` to reflect the valid states. ## Tests Added 2 new tests: 1. `unstable_cache re-fetches when entry is stale (time-expired)` — verifies stale entries trigger re-computation 2. `unstable_cache with no revalidate option caches indefinitely` — verifies `revalidateAt` is `null` (not `0`) when no revalidate is specified --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>