What causes " || Failed to authorize debug session" in windmill-labs/windmill?

Inspect the thrown message and the corresponding network response status in devtools to identify the backend rejection.

<server error text> || Failed to authorize debug session

Error message

<server error text> || Failed to authorize debug session

What it means

signDebugRequest's generic failure path: when POST /api/w/{workspace}/debug/sign returns a non-OK status and the body does not contain 'not initialized', the server's error text (or the fallback 'Failed to authorize debug session' if the body is empty) is thrown verbatim. This is a pass-through of any backend rejection during debug-session signing — auth, permission, or validation errors included.

Source

Thrown at frontend/src/lib/components/debug/debugUtils.ts:72

): Promise<{ token: string; code: string; job_id: string }> {
	if (!workspace) {
		throw new Error('No workspace selected')
	}

	const response = await fetch(`/api/w/${workspace}/debug/sign`, {
		method: 'POST',
		headers: { 'Content-Type': 'application/json' },
		body: JSON.stringify({ code, language })
	})

	if (!response.ok) {
		const errorText = await response.text()
		if (errorText.includes('not initialized')) {
			throw new Error(
				'Debug signing is not configured on the server. Please contact your administrator.'
			)
		}
		throw new Error(errorText || 'Failed to authorize debug session')
	}

	return await response.json()
}

/**
 * Sign a multiplayer session request. Returns a JWT token that the
 * multiplayer server will verify before accepting the WebSocket connection.
 */
export async function signMultiplayerRequest(workspace: string): Promise<string> {
	if (!workspace) {
		throw new Error('No workspace selected')
	}

	const response = await fetch(`/api/w/${workspace}/debug/sign_multiplayer`, {
		method: 'POST',
		headers: { 'Content-Type': 'application/json' },
		body: JSON.stringify({})

View on GitHub (pinned to e474e8803c)

Solutions

Inspect the thrown message and the corresponding network response status in devtools to identify the backend rejection.
For 401/403: re-login or request debugger/run permissions on the workspace, then retry.
For 404: confirm the workspace id and that the backend version supports /debug/sign.
For 5xx/empty bodies: check backend/proxy logs; retry once the server is healthy.

Defensive patterns

Strategy: try-catch

Try / catch

try { await signDebugRequest(ws, code, lang) } catch (e) { toast(getDebugErrorMessage(e)); console.warn('debug sign failed', e) }

Prevention

Refresh auth tokens before long-lived editor sessions issue signed requests.
Verify workspace membership/permissions before offering debug actions.
Handle empty server error bodies by always wrapping with getDebugErrorMessage().

When it happens

Trigger: Any non-2xx from /debug/sign other than the 'not initialized' case: 401/403 (expired token, lacking run permission on the workspace), 404 (workspace or route missing), 400 (invalid code/language payload), 5xx from a proxy, or an empty error body triggering the fallback message.

Common situations: User token expired or lacks debugger permissions; workspace deleted/renamed; reverse proxy returning an HTML error page (502/503) with no useful text; backend down; payload rejected because the language string is misspelled.

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/640dda63bf5f9e9c. Report an issue: GitHub.