windmill-labs/windmill · error

trigger kind '${trigger.kind}' not supported yet

Error message

trigger kind '${trigger.kind}' not supported yet

What it means

createWorkspaceTriggerDisabled validates a trigger coming from a project/template install against the TRIGGER_KINDS registry before creating it. If the trigger's kind is not a known WorkspaceTriggerKind, this error is thrown. It protects the installer from attempting to create trigger kinds the current build does not support.

Source

Thrown at frontend/src/lib/components/triggers/workspaceTriggersList.ts:409

/**
 * Create a trigger in its disabled state — the semantics differ per kind
 * (schedules use `enabled: false`, every other kind uses `mode: 'disabled'`)
 * and are encoded here once so importers can't get them wrong.
 */
export async function createWorkspaceTriggerDisabled(
	workspace: string,
	trigger: {
		kind: string
		path: string
		script_path: string
		is_flow: boolean
		summary?: string | null
		config?: Record<string, any> | null
	},
	opts: { hasEeLicense: boolean }
): Promise<unknown> {
	const def = TRIGGER_KINDS[trigger.kind as WorkspaceTriggerKind]
	if (!def) throw new Error(`trigger kind '${trigger.kind}' not supported yet`)
	if (def.eeOnly && !opts.hasEeLicense) {
		throw new Error(`trigger kind '${trigger.kind}' requires Enterprise`)
	}
	if (def.provisionsOnCreate) {
		throw new Error(
			`${def.badge} triggers manage cloud subscriptions at creation — fill in the imported resource, then re-create this trigger manually`
		)
	}
	// Remote input: only the allowlisted portable slice may reach the create call.
	const config = portableTriggerConfig(trigger.kind, trigger.config)
	if (trigger.kind === 'schedule') {
		// Spread the portable config first so behavioral settings survive the
		// import (cron_version, retry, failure/recovery/success handlers,
		// no_flow_overlap, …) — restoring only cron+timezone would silently
		// change the schedule's semantics once re-enabled.
		return ScheduleService.createSchedule({
			workspace,
			requestBody: {

View on GitHub (pinned to e474e8803c)

Solutions

  1. Check the kind in the error message against TRIGGER_KINDS keys and fix the project/template definition.
  2. Upgrade Windmill so both sides support the trigger kind.
  3. Skip or warn on unsupported triggers during install instead of failing the whole project.
  4. If the kind was renamed, update the template to the new kind name.

Example fix

// before
const def = TRIGGER_KINDS[trigger.kind as WorkspaceTriggerKind]
if (!def) throw new Error(`trigger kind '${trigger.kind}' not supported yet`)
// after
const def = TRIGGER_KINDS[trigger.kind as WorkspaceTriggerKind]
if (!def) {
  console.warn(`trigger kind '${trigger.kind}' not supported yet; skipping during install`)
  return null
}
Defensive patterns

Strategy: validation

Validate before calling

function isSupportedWorkspaceTriggerKind(kind: string): kind is WorkspaceTriggerKind {
  return kind in TRIGGER_KINDS
}
// before install:
const supported = triggers.filter((t) => isSupportedWorkspaceTriggerKind(t.kind))

Type guard

function isWorkspaceTriggerKind(k: string): k is WorkspaceTriggerKind {
  return k in TRIGGER_KINDS
}

Try / catch

try {
  await createWorkspaceTriggerDisabled(trigger, { hasEeLicense })
} catch (e) {
  if (String(e).includes('not supported yet')) {
    warnings.push(`Skipped ${trigger.kind}: unsupported in this version`)
    return null
  }
  throw e
}

Prevention

When it happens

Trigger: installProject calls createWorkspaceTriggerDisabled with a trigger whose `kind` string is not a key of TRIGGER_KINDS — new kinds from a newer export, typos in a project template, or renamed kinds.

Common situations: Importing a project authored on a newer Windmill version; hand-edited project/template YAML with an invalid kind; frontend/backend version skew where one side knows a kind the other does not.

Related errors


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