Summary
In the official Docker v2.4.0 image, the browser requests the Automerge WASM asset with an URL-encoded ?dpl=... (deploymentId query) embedded into the file name, and the request 404s. This blocks WebAssembly.compile and prevents the encrypted-sync engine from initializing at all.
Steps to reproduce
- Deploy
ghcr.io/u14app/neo-chat:v2.4.0 via Docker behind a reverse proxy.
- Open the app and navigate to Settings → Sync (this triggers loading the Automerge WASM asset).
- In the browser network panel or server access log, observe:
GET /_next/static/chunks/<hash>.wasm%3Fdpl%3Dbuild-xxxxxxxx?dpl=build-xxxxxxxx → 404
- The UI shows:
Failed to execute 'compile' on 'WebAssembly': HTTP status code is not ok.
The file does exist inside the container:
/app/.next/static/chunks/<hash>.wasm
Requesting the correct URL returns 200 with Content-Type: application/wasm.
Expected behavior
The WASM asset URL should be /_next/static/chunks/<hash>.wasm — the deploymentId, if used, belongs in the query string only, not percent-encoded into the asset file name — so the asset resolves and WebAssembly.compile succeeds.
Actual behavior
The malformed request 404s and sync cannot start. After a minimal nginx rewrite that strips only the encoded ?dpl=... portion from .wasm file names, the same request returns 200 and the WebAssembly error disappears — confirming the URL pollution is the sole cause of the 404.
Environment
Browser: Chrome 151 (macOS 15)
Deployment: official Docker image ghcr.io/u14app/neo-chat:v2.4.0, nginx reverse proxy, Cloudflare Tunnel in front
Logs or screenshots
Access log (client and host redacted):
"GET /_next/static/chunks/3kss9-ir6pd-c.wasm%3Fdpl%3Dbuild-ms9x9138-1cd9e864?dpl=build-ms9x9138-1cd9e864 HTTP/1.1" 404
After stripping only the encoded portion from the path, the same request returns 200, 3380509 bytes, application/wasm.
Investigation leads
next.config.ts: deploymentId / NEXT_DEPLOYMENT_ID / NEXT_PUBLIC_DEPLOYMENT_ID- Interaction between the deployment-version query Next.js appends to static assets and the dynamic
new URL(..., import.meta.url)-style WASM asset URL used by @automerge/automerge — the ?dpl=... suffix appears to end up percent-encoded as part of the asset file name.
- Not yet reproduced with a local official-image build; the production evidence above is unambiguous.
Summary
In the official Docker v2.4.0 image, the browser requests the Automerge WASM asset with an URL-encoded
?dpl=...(deploymentId query) embedded into the file name, and the request 404s. This blocksWebAssembly.compileand prevents the encrypted-sync engine from initializing at all.Steps to reproduce
ghcr.io/u14app/neo-chat:v2.4.0via Docker behind a reverse proxy.Failed to execute 'compile' on 'WebAssembly': HTTP status code is not ok.The file does exist inside the container:
Requesting the correct URL returns
200withContent-Type: application/wasm.Expected behavior
The WASM asset URL should be
/_next/static/chunks/<hash>.wasm— the deploymentId, if used, belongs in the query string only, not percent-encoded into the asset file name — so the asset resolves andWebAssembly.compilesucceeds.Actual behavior
The malformed request 404s and sync cannot start. After a minimal nginx rewrite that strips only the encoded
?dpl=...portion from.wasmfile names, the same request returns 200 and the WebAssembly error disappears — confirming the URL pollution is the sole cause of the 404.Environment
Browser: Chrome 151 (macOS 15)
Deployment: official Docker image
ghcr.io/u14app/neo-chat:v2.4.0, nginx reverse proxy, Cloudflare Tunnel in frontLogs or screenshots
Access log (client and host redacted):
After stripping only the encoded portion from the path, the same request returns
200,3380509bytes,application/wasm.Investigation leads
next.config.ts:deploymentId/NEXT_DEPLOYMENT_ID/NEXT_PUBLIC_DEPLOYMENT_IDnew URL(..., import.meta.url)-style WASM asset URL used by@automerge/automerge— the?dpl=...suffix appears to end up percent-encoded as part of the asset file name.