windmill-labs/windmill · error · Error

export ${res.status}: ${text}

Error message

export ${res.status}: ${text}

What it means

#ensureExport in the import wizard's execution store fetches the full project export through the server-side proxy endpoint `/api/w/<workspace>/hub/projects/<slug>/export` (credentials included, so a private hub reachable from the server works). On a non-OK response it throws `export <status>: <body text>` and marks the fetch step 'failed'. The embedded body text is the server's own error detail.

Source

Thrown at frontend/src/lib/importWizard/execution.svelte.ts:320

		this.#set('create', 'done')
		return d.id
	}

	async #ensureExport(workspace: string): Promise<ProjectExport | undefined> {
		if (this.#export) {
			this.#set('fetch', 'done')
			return this.#export
		}
		this.#set('fetch', 'running')
		try {
			// Workspace-scoped on purpose: this is the same proxy the rest of the app
			// uses, so a private hub reachable only from the server still works.
			const res = await fetch(
				`/api/w/${encodeURIComponent(workspace)}/hub/projects/${encodeURIComponent(this.#plan.slug)}/export`,
				{ credentials: 'include', headers: { accept: 'application/json' } }
			)
			const text = await res.text()
			if (!res.ok) throw new Error(`export ${res.status}: ${text}`)
			this.#export = JSON.parse(text) as ProjectExport
			this.#set('fetch', 'done', `${itemCount(this.#export)} items`)
			return this.#export
		} catch (e: any) {
			const detail = e?.message ?? String(e)
			this.#set('fetch', 'failed', detail)
			this.error = `Could not read the project: ${detail}`
			return undefined
		}
	}

	/**
	 * Leave the checklist saying what actually happened, from wherever the run stopped.
	 *
	 * Reached from every point after `import` goes `running`, so nothing is left spinning on a
	 * run that has ended. A partial import is failed rather than done: calling it done reports
	 * a clean import over items that never started, and the resumed step offers Continue where
	 * it should offer Retry.

View on GitHub (pinned to e474e8803c)

Solutions

  1. Read the body text appended to the message — it contains the server's upstream error detail.
  2. Confirm the hub project slug exists and the backend's hub configuration points at the right hub.
  3. Re-login if the status is 401/403 so the cookie credentials are valid.
  4. Retry on 5xx; check hub availability and backend logs for the proxy error.
Defensive patterns

Strategy: try-catch

Validate before calling

const ping = await fetch(`/api/w/${workspace}/hub/projects/${slug}/export`, { method: 'HEAD', credentials: 'include' })
if (ping.status === 401) redirectLogin()
if (ping.status === 404) alert('project not found on the hub configured for this server')

Try / catch

try {
  await wizard.exportData()
} catch (e) {
  wizard.set('fetch', 'failed', e.message) // message already includes status + body
  const status = /^export (\d+)/.exec(e.message)?.[1]
  if (status === '401') promptReLogin()
  else if (status?.startsWith('5')) offerRetry()
}

Prevention

When it happens

Trigger: exportData drives the wizard; the backend proxy to the hub returns non-200 — hub project missing (404), hub unreachable from the server (502/500), auth issue on the workspace endpoint (401/403), or hub 5xx.

Common situations: Private hub reachable only from the server but misconfigured (wrong hub URL on the backend); slug exists in the UI but not on the hub the server talks to; expired session (401) if credentials aren't sent; hub rate limiting.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.

Related errors

AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03). Data as JSON: /api/errors/ed153018422546a3. Report an issue: GitHub.