Reusing Fetch Options Removes `Next` Configuration And Can Break Prerendering

In packages/next/src/server/lib/patch-fetch.ts, the patched fetch function receives the caller's init object by reference. On a cache miss, it deletes init.next (and init.cache on edge runtime) to strip Next.js-specific fields before forwarding to the origin. This mutation modifies the original object, so any reuse of that object (e.g., module-level constants) loses the cache settings for later calls.

1. Clone repro branch: git clone --branch repro/fetch-options-mutation --single-branch https://github.com/iamibi/next.js.git 2. cd next.js && npm install 3. Run npx next info (optional) 4. Remove .next and run npx next build -> observe prerender error 'Next.js encountered uncached or runtime data during prerendering.' 5. Remove .next and run npx next dev -> in another terminal run curl -s http://localhost:3000/ | grep -o '<p id="[a-z]*">[^<]*</p>' twice. Notice that both first and second values change on each request, despite revalidate: 3600. 6. As control, replace fetchOptions with a fresh object literal at call site: { next: { revalidate: 3600, tags: ['shared'] } }, rebuild and dev; route table shows static route and dev values remain stable.

The shallow copy only clones top-level properties; if init contains nested objects other than next or cache, they are shared by reference, but that is not relevant for the removed fields. Ensure that the copy is used consistently for the entire origin fetch call to avoid subtle bugs. Rollback: revert to direct deletion on init if the copy introduces unexpected behavior, but this would reintroduce the mutation bug. Test with frozen objects and in concurrent fetch scenarios to verify no regressions.