Crash on cached page load w/ cloudflare-pages

[flaming-codes]

Describe the bug

Summary

A page that is configured to be cached and deployed to Cloudflare Pages will crash on load with a 500 (see attached log in this report).

This is most likely a bug with Cloudflare Pages, as credentials: 'omit' apparently leads to a delete of credentials in RequestInitializerDict, yet appears to be accessed by Cloudflare.

Notes

This issue only happens when the page gets called directly. When navigating to the cached page from another page, i.e. using client-side routing, load works as expected.

Reproduction

Repo

https://github.com/flaming-codes/sveltekit-cloudflare-cache-issue

Live demo

https://070b0bb1.sveltekit-cloudflare-cache-issue.pages.dev/posts/slug-101

Steps to reproduce

1. Deploy on Cloudflare pages
2. Go to landing page
3. Click Posts Page
4. Click Open posts detail page
5. Page loads
6. Reload, see error

Logs

500
The 'credentials' field on 'RequestInitializerDict' is not implemented.
Error: The 'credentials' field on 'RequestInitializerDict' is not implemented.

System Info

System:
    OS: Linux 5.4 Ubuntu 20.04.3 LTS (Focal Fossa)
    CPU: (4) x64 Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
    Memory: 1.05 GB / 7.77 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 14.17.6 - ~/.nodejs/current/bin/node
    Yarn: 1.22.15 - /opt/yarn/stable/bin/yarn
    npm: 6.14.15 - ~/.nodejs/current/bin/npm
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.17 
    @sveltejs/kit: next => 1.0.0-next.260 
    svelte: ^3.44.0 => 3.46.4

Severity

blocking all usage of SvelteKit

Additional Information

I marked it as blocking all usage, as this effectively blocks me from developing a CMS-heavy site. No caching just isn't an option, and direct loading of the page has to work from cache.

[Rich-Harris]

Confirmed that this is still the case with the current version and the worker environment. As far as I can tell (it's tricky, because I can't figure out how to deobfuscate the line numbers in the stack trace) the offending line is this one:

kit/packages/kit/src/runtime/server/page/load_node.js

Lines 189 to 193 in d4ec813

	response = await respond(new Request(new URL(requested, event.url).href, opts), options, {
	getClientAddress: state.getClientAddress,
	initiator: route,
	prerender: state.prerender
	});

You can't use credentials when creating a Request in a worker. On one level this makes sense (it wouldn't mean anything), though I do wonder if it should just be quietly ignored instead of blowing up. cc'ing @lukeed for visibility. I've opened #4548 which will hopefully fix this issue.

[flaming-codes]

Will close issue, as the bug isn't reproducible after the latest fix from @Rich-Harris.

[OttoHatt]

It looks like this patch is breaking fetch with Wrangler 2 when emulating pages.

TypeError: Failed to construct 'Request': The provided value 'undefined' is not a valid enum value of type RequestCredentials.
    at new Request (C:\Users\...\Downloads\wrangler depo\node_modules\undici\lib\fetch\request.js:288:15)
    at new Request (C:\Users\...\Downloads\wrangler depo\node_modules\@miniflare\core\src\standards\http.ts:407:13)
    at Object.construct (C:\Users\...\Downloads\wrangler depo\node_modules\@miniflare\core\src\plugins\core.ts:69:29)
    at fetch (C:\Users\...\Documents\planorama\planorama\.svelte-kit\cloudflare\_worker.js:4361:36)
    ...

Replacing the override to set credentials to undefined (i.e. replacing it with omit) works and fixes the problem. Looks like credentials is now implemented in the CF runtime, so this hack is no longer needed??