Review: fix(cache): attach path tags to prerender-seeded entries

Tested locally — all 93 tests pass across the 3 modified test files. The fix is correct and well-scoped.

Correctness trace

The core bug: isrSetPrerenderedAppPage and buildTprKVPairs wrote entries with tags: []. When revalidatePath('/foo') fires, it calls handler.revalidateTag(encodeCacheTag('_N_T_/foo')), which marks that tag as invalidated. On the next handler.get(), entries are checked against invalidated tags — but entries with no tags can never match, so they persist until natural TTL expiry.

The fix correctly uses buildAppPageCacheTags(pathname, []) at all three seeding sites, which is the same function used by the runtime render path in app-page-cache.ts when writing cache entries after a fresh render. This ensures seeded entries and runtime-rendered entries carry identical tag sets, so revalidatePath invalidates both uniformly.

Tag matching trace for revalidatePath('/foo'):

• revalidatePath('/foo') → tag = _N_T_/foo → handler.revalidateTag('_N_T_/foo')
• buildAppPageCacheTags('/foo', []) produces ['/foo', '_N_T_/foo', '_N_T_/layout', '_N_T_/foo/layout', '_N_T_/foo/page']
• _N_T_/foo is in the set — match. Correct.

One behavioral discrepancy to consider (non-blocking)

isrSet (the runtime write path) always passes tags: tags ?? [] in the context — it explicitly includes an empty array when no tags are provided. The refactored isrSetPrerenderedAppPage uses:

if (tags && tags.length > 0) {
  ctx.tags = tags;
}

This means when tags is undefined or empty, the context object has no tags key at all, whereas isrSet would pass tags: [].

For the built-in MemoryCacheHandler and KVCacheHandler this is safe — they both handle missing tags gracefully. But a custom CacheHandler implementation that distinguishes between ctx.tags === undefined and ctx.tags === [] could behave differently for seeded vs runtime entries. This is an extremely unlikely edge case and not blocking, but worth noting for future parity. The guard tags.length > 0 is arguably more correct anyway (why store empty metadata?), but it's a deliberate divergence from isrSet's convention.

TPR path normalization

buildTprKVPairs feeds routePath (raw path from Cloudflare analytics) directly into buildAppPageCacheTags. The cache key is built via isrCacheKey("app", routePath, buildId) which normalizes trailing slashes. However, buildAppPageCacheTags does not normalize its input — if analytics returns /foo/ with a trailing slash, the tags would be ['/foo/', '_N_T_/foo/', ...] while revalidatePath('/foo') would produce _N_T_/foo. This is pre-existing (the cache key itself was already built from the raw path), and the filterTrafficPaths function filters paths that don't start with / but doesn't strip trailing slashes. Not a regression from this PR, just documenting the existing gap.

Test quality

Excellent test coverage:

• End-to-end revalidatePath through the KV handler with page/layout/bare variants
• Sibling isolation (invalidating /blog/hello doesn't affect /blog/world)
• Root path / edge case
• Prerender-seeded entry invalidation via isrSetPrerenderedAppPage
• Regression guard documenting legacy no-tags behavior
• Seed cache integration test verifying both HTML and RSC artifacts are invalidated
• TPR tag assertion

The void revalidateTag; at the bottom of kv-cache-handler.test.ts looks like it exists to prevent the import from being tree-shaken or flagged as unused — since revalidateTag is imported but only referenced indirectly via revalidatePath. Minor style nit but not worth changing.

Summary

Clean fix, correct approach, good tests. The PR description accurately scopes what's covered (path invalidation) vs what's deferred (rewrite-aware invalidation). Ship it.