@sveltejs/adapter-cloudflare Error: Could not create a fallback page — failed with status 307

[buhodev]

Describe the bug

I am trying to use Inlang for i18n with the SDK for SvelteKit. For the language negotiation option I set the strategy to be "URL".

// inlang.config.js
export async function defineConfig(env) {
	...
	return {
		referenceLanguage: 'en',
		plugins: [
			jsonPlugin({ pathPattern: './languages/{language}.json' }),
			standardLintRules(),
			sdkPlugin({
				languageNegotiation: {
					strategies: [{ type: 'url' }]
				}
			})
		]
	};
}

If I run the dev server, I get this error:

[vite-plugin-inlang-sdk-js-sveltekit]
Could not find the folder '\src\routes\[lang]'.
It is needed in order to circumvent a current limitation of SvelteKit. See https://github.com/inlang/inlang/issues/647.
Please create the folder and move all existing route files into it.

This is expected.

I just create the dynamic route and move my pages there (this is not the problem). Everything goes well if I run my dev server.

The problem is that when I build the project with adapter-cloudflare, it goes fine until the adapter kicks in:

> Using @sveltejs/adapter-cloudflare

node:internal/event_target:1010
  process.nextTick(() => { throw err; });
                           ^
Error: Could not create a fallback page — failed with status 307
    at generate_fallback (file:///C:/Users/Carlos/Projects/melt-ui-test/node_modules/.pnpm/@[email protected][email protected][email protected]/node_modules/@sveltejs/kit/src/core/postbuild/fallback.js:53:8)
    at async MessagePort.<anonymous> (file:///C:/Users/Carlos/Projects/melt-ui-test/node_modules/.pnpm/@[email protected][email protected][email protected]/node_modules/@sveltejs/kit/src/utils/fork.js:22:16)
Emitted 'error' event on Worker instance at:
    at [kOnErrorMessage] (node:internal/worker:290:10)
    at [kOnMessage] (node:internal/worker:301:37)
    at MessagePort.<anonymous> (node:internal/worker:202:57)
    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:735:20)
    at exports.emitMessage (node:internal/per_context/messageport:23:28)

Node.js v18.15.0

However, if I downgrade the @sveltejs/adapter-cloudflare to v2.1.0, it builds successfully.

> Using @sveltejs/adapter-cloudflare
  ✔ done
✓ built in 18.64s

I think this might be happening because if I set the strategy to be "url" in the inlang config, we need to add all our pages inside a dynamic lang param at the root of the routes folder: routes/[lang]/+page.svelte so that Inlang can detect the locale based on the url and do automatic language specific routing. And this is what generates the problem.

There's another workaround (different than downgrading the adapter): set the language strategy to be 'localStorage', move the pages from routes/[lang]/+page.svelte to routes/+page.svelte and the error disappears!

// inlang.config.js
export async function defineConfig(env) {
	...
	return {
		referenceLanguage: 'en',
		plugins: [
			jsonPlugin({ pathPattern: './languages/{language}.json' }),
			standardLintRules(),
			sdkPlugin({
				languageNegotiation: {
-					strategies: [{ type: 'url' }]
+					strategies: [{ type: 'localStorage' }]
				}
			})
		]
	};
}

console:

> Using @sveltejs/adapter-cloudflare
  ✔ done
✓ built in 18.74s

Reproduction

https://github.com/buhodev/melt-ui-starter/

To see the bug:

1. Run build command and see the error when adapter-cloudflare kicks in.

1st workaround:

1. Set the language strategy to be 'localStorage' instead of 'url' inside the inlang.config.js file
2. Move the page from routes/[lang]/+page.svelte to routes/+page.svelte
3. Build the project
4. The error disappears

2nd workaround:

1. Downgrade @sveltejs/adapter-cloudflare

"devDependencies": {
-	"@sveltejs/adapter-cloudflare": "^2.3.1",
+	"@sveltejs/adapter-cloudflare": "^2.1.0",
},

2. Build the project
3. The error disappears

Logs

> Using @sveltejs/adapter-cloudflare

node:internal/event_target:1010
  process.nextTick(() => { throw err; });
                           ^
Error: Could not create a fallback page — failed with status 307
    at generate_fallback (file:///C:/Users/Carlos/Projects/melt-ui-test/node_modules/.pnpm/@[email protected][email protected][email protected]/node_modules/@sveltejs/kit/src/core/postbuild/fallback.js:53:8)
    at async MessagePort.<anonymous> (file:///C:/Users/Carlos/Projects/melt-ui-test/node_modules/.pnpm/@[email protected][email protected][email protected]/node_modules/@sveltejs/kit/src/utils/fork.js:22:16)
Emitted 'error' event on Worker instance at:
    at [kOnErrorMessage] (node:internal/worker:290:10)
    at [kOnMessage] (node:internal/worker:301:37)
    at MessagePort.<anonymous> (node:internal/worker:202:57)
    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:735:20)
    at exports.emitMessage (node:internal/per_context/messageport:23:28)

Node.js v18.15.0

System Info

System:
    OS: Windows 10 10.0.22621
    CPU: (12) x64 AMD Ryzen 5 5500U with Radeon Graphics
    Memory: 839.90 MB / 7.33 GB
  Binaries:
    Node: 18.15.0 - ~\AppData\Local\Volta\tools\image\node\18.15.0\node.EXE
    npm: 9.5.0 - ~\AppData\Local\Volta\tools\image\node\18.15.0\npm.CMD
    pnpm: 8.6.5 - C:\Program Files\Volta\pnpm.EXE
  Browsers:
    Edge: Spartan (44.22621.1928.0), Chromium (114.0.1823.79)
    Internet Explorer: 11.0.22621.1
  npmPackages:
    @sveltejs/adapter-auto: ^2.0.0 => 2.1.0
    @sveltejs/adapter-cloudflare: ^2.3.1 => 2.3.1
    @sveltejs/kit: ^1.20.4 => 1.22.1
    svelte: ^4.0.0 => 4.0.5
    vite: ^4.3.6 => 4.4.2

Severity

blocking an upgrade

Additional Information

It seems related to this issue #9386 that is caused by this update #9294

[ghostdevv]

This is definitely a duplicate of #9386 caused by #9294

In terms of your issue, I don't know anything about inlang but figuring out why it's causing a 307 when trying to render the fallback and preventing that would be the quickest workaround IMO

[ivanhofer]

@buhodev this has been fixed in version 0.9.1 of @inlang/sdk-js.
The issue was that the cloudflare adapter tries generates a 404.html page and therefore makes a request to /[fallback] which should render a 404 page. The SDK now ignores that request.