windmill-labs/windmill · error · Error

inlineScript is required when runnable type is "inline".

Error message

inlineScript is required when runnable type is "inline".

What it means

When building a persisted runnable reference for an app backend module, the type:"inline" branch requires an `inlineScript` payload (the actual script content). If type is "inline" but inlineScript is missing, core.ts throws this error instead of producing an invalid runnable.

Source

Thrown at frontend/src/lib/components/copilot/chat/global/core.ts:1629

		: (existing?.fields ?? {})

	// Converting between kinds must drop the other kind's fields. Every consumer dispatches on
	// `type` (isRunnableByName / isRunnableByPath), so a leftover does not change which code
	// runs — it contradicts it: a runnable reported back as inline still names a flow in
	// `path`, and that is what the model reads on its next turn.
	const { runType: _runType, path: _path, inlineScript: _inlineScript, ...carried } = existing ?? {}

	// `schema` describes the item a path runnable points at, so it only survives while that
	// target is unchanged. Carried across a retarget it types `backend.<key>(args)` from the
	// previous item's inputs, because hiddenRunnableToTsType reads it for the path branch.
	const sameTarget =
		(existing?.type === 'path' || existing?.type === 'runnableByPath') &&
		existing?.runType === input.type &&
		existing?.path === input.path

	if (input.type === 'inline') {
		if (!input.inlineScript) {
			throw new Error('inlineScript is required when runnable type is "inline".')
		}
		return {
			...carried,
			name: input.name,
			type: 'inline',
			inlineScript: {
				content: input.inlineScript.content,
				language: input.inlineScript.language
			},
			fields
		}
	}

	if (!input.path) {
		throw new Error('path is required when runnable type is "script", "flow", or "hubscript".')
	}
	return {
		...carried,

View on GitHub (pinned to e474e8803c)

Solutions

  1. Provide inlineScript with the script content when type is "inline".
  2. If you meant to reference an existing script, use type "script" (or "flow"/"hubscript") with a path instead.
  3. Check that the upstream step producing the script body actually succeeded and its value is defined.
  4. Validate the input object has inlineScript before calling the tool.

Example fix

// before
runnable({ type: 'inline', name: 'fetch' })
// after
runnable({ type: 'inline', name: 'fetch', inlineScript: { language: 'python3', content: '...' } })
Defensive patterns

Strategy: validation

Validate before calling

if (input.type === 'inline' && !input.inlineScript) {
  throw new Error('provide inlineScript for inline runnables')
}

Type guard

function isInlineRunnable(i: RunnableInput): i is RunnableInput & { inlineScript: object } {
  return i.type !== 'inline' || (i as any).inlineScript != null
}

Try / catch

try {
  await createRunnable(input)
} catch (e) {
  if (e.message.includes('inlineScript is required')) {
    await createRunnable({ ...input, type: 'script', path: existingScriptPath })
  }
}

Prevention

When it happens

Trigger: Calling the runnable-creating tool with { type: 'inline', name: '...' } but omitting inlineScript; inlineScript was null/undefined because a previous step that was supposed to supply the script body did not run.

Common situations: The AI drops the inlineScript field when generating tool args; the caller intends to reference a script by path but sets type to "inline" by mistake; an optional-script param defaulted to undefined.

Understand the failure class

Background: "missing required argument" and "the following required arguments were not provided": what required-argument errors mean and how to fix them — this error's family across 20 libraries.

Related errors


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