## Summary
- migrate Cache Components, PPR, prefetching, prerendering,
revalidation, and SSG deployment exclusions to `@force-gate`
- remove the corresponding `skipDeployment` options and `skipped`
control flow while preserving each suite's rationale
This keeps caching-related exclusions together so their deployed
semantics can be reviewed by the same owners.
## Verification
- verified on the combined top-of-stack tree with `pnpm typescript`
- compared ordinary-mode collection before and after: all 4,670 existing
test names matched
- collected all 510 affected files in deploy mode: 4,578 skipped tests,
zero failures
<!-- NEXT_JS_LLM -->
When a custom `"use cache"` cache handler's `get` method throws, the
error was logged up to four times for a single request: once as the
intended rendering error (`⨯ Error: ... { digest }`), and up to three
more times through the various `unhandledRejection` handlers (the
runtime's plain `console.error` in `process-error-handlers.ts`, the
router server's `Log.error`, and the dev overlay's log forwarding).
All the redundant logs stemmed from the same root cause:
`ResolvableSharedCacheResult` stores its deferred promise in the dedup
maps (`pendingCacheInvocations` / `crossRequestPendingCacheInvocations`)
so concurrent invocations can join the leader. That promise has no
consumer unless another invocation actually joins it, so when the
leader's cache access failed, the rejected promise was left behind
without a rejection handler, and Node.js reported it as an unhandled
rejection that fanned out to every installed handler.
This is relevant if the cache is in a broken state or the keys or
entries are not suitable (e.g. an entry that's to large to be stored).
Revealed several oddities:
1. cache handler have no no sources content (not too bad since that
means the codeframe points into the problem `use cache` function which
is usually the cause)
2. A throwing `set` is swallowed in dev
3. A throwing `get` is logged as a caught error and an unhandled
rejection. This is spammy.
Josh Story