GraphiteEditor/Graphite · critical

Failed to fetch Wasm binary part (status ${failedResponse.st

Error message

Failed to fetch Wasm binary part (status ${failedResponse.status}): ${failedResponse.url}

What it means

Graphite splits large Wasm binaries into chunks: when the build-time constant __WASM_PART_COUNT__ exceeds 1, initWasm() fetches every -partN.wasm file in parallel and any non-ok response aborts with this error before wasm-bindgen's init() runs. The editor cannot boot without the binary, and the service-worker precache install (which normally guarantees these files) is the usual upstream guarantee being violated.

Source

Thrown at frontend/src/utility-functions/wasm-loader.ts:18

import init from "/wrapper/pkg/graphite_wasm_wrapper";
import wasmBinaryUrl from "/wrapper/pkg/graphite_wasm_wrapper_bg.wasm?url";

// Initializes the editor's Wasm module, rejoining the parts that CI deployments split the binary into
// to fit under the single-file size limit (see `wasmSplitting` in `vite.config.ts`)
export async function initWasm() {
	// Local and native builds keep the binary whole, letting the wasm-bindgen glue code load it directly
	if (__WASM_PART_COUNT__ <= 1) return init();

	// Fetch all parts in parallel (served from the service worker's precache once it is installed)
	const partRequests = [];
	for (let index = 0; index < __WASM_PART_COUNT__; index += 1) {
		partRequests.push(fetch(wasmBinaryUrl.replace(/\.wasm$/, `-part${index}.wasm`)));
	}
	const partResponses = await Promise.all(partRequests);

	const failedResponse = partResponses.find((response) => !response.ok);
	if (failedResponse) throw new Error(`Failed to fetch Wasm binary part (status ${failedResponse.status}): ${failedResponse.url}`);

	// Rejoin the parts and hand them to wasm-bindgen as a single response, with the MIME type needed for streaming compilation
	const parts = await Promise.all(partResponses.map((response) => response.blob()));
	const joined = new Response(new Blob(parts), { headers: { "Content-Type": "application/wasm" } });
	// eslint-disable-next-line camelcase
	return init({ module_or_path: joined });
}

View on GitHub (pinned to c507b35645)

Solutions

  1. Open the failed URL printed in the error (failedResponse.url) and confirm the status — usually 404 for a missing part
  2. Redeploy the complete build output so every -partN.wasm referenced by the bundle exists on the server
  3. Verify the vite base/publicPath so wasmBinaryUrl points at the directory that actually contains the parts
  4. Hard-reload or unregister the old service worker so the new precache manifest repopulates the part files

Example fix

// before
const partResponses = await Promise.all(partRequests);
const failedResponse = partResponses.find((response) => !response.ok);
if (failedResponse) throw new Error(`Failed to fetch Wasm binary part (status ${failedResponse.status}): ${failedResponse.url}`);

// after: retry each part once before failing boot
async function fetchPart(url) {
	let last;
	for (let attempt = 0; attempt < 2; attempt += 1) {
		try {
			const r = await fetch(url);
			if (r.ok) return r;
			last = r;
		} catch (e) { last = e; }
	}
	throw last;
}
const partResponses = await Promise.all(
	Array.from({ length: __WASM_PART_COUNT__ }, (_, index) => fetchPart(wasmBinaryUrl.replace(/\.wasm$/, `-part${index}.wasm`))),
);
Defensive patterns

Strategy: retry

Validate before calling

// Verify all part URLs resolve before booting the editor
async function partsAvailable(baseUrl: string, count: number): Promise<boolean> {
	const checks = await Promise.all(
		Array.from({ length: count }, (_, i) => fetch(baseUrl.replace(/\.wasm$/, `-part${i}.wasm`), { method: "HEAD" })),
	);
	return checks.every((r) => r.ok);
}

Try / catch

// Catch at boot, log the failed part, and offer a reload (reload re-runs SW install and repopulates the precache)
try {
	await initWasm();
} catch (err) {
	console.error(err);
	showFatalError("Editor failed to load. Reload to retry.");
}

Prevention

When it happens

Trigger: A part file missing on the server: 404 from a partial deploy; wrong vite base/publicPath so wasmBinaryUrl resolves to the wrong directory; an old service-worker precache referencing part URLs that no longer exist after a redeploy; a dev server that has not emitted the split parts.

Common situations: Deploys that upload the main bundle but drop some hashed -partN.wasm files; CDN cache purged mid-deploy; switching between whole-binary and split builds while a stale service worker serves old URLs; hosting under a subpath with a misconfigured base URL.

Related errors


AI-assisted analysis of GraphiteEditor/Graphite@c507b35645 (2026-08-16). Data as JSON: /api/errors/d0f4e5e4479a4580. Report an issue: GitHub.