Unsupported schedule target type: ${(schedule.target as { ty

Error message

Unsupported schedule target type: ${(schedule.target as { type: string }).type}

What it means

#publishTargetStart throws when a schedule's target object has a `type` the scheduler does not recognize in its switch statement. It is an exhaustive-dispatch guard: only registered target types (e.g. workflow/step/event) are supported.

Source

Thrown at packages/core/src/workflows/scheduler/scheduler.ts:499

          localOnly ? { localOnly: true } : undefined,
        );
        return;
      }
      case 'agent': {
        await this.#pubsub.publish(TOPIC_AGENT_SCHEDULES, {
          type: 'agent-schedule.fire',
          runId: claimId,
          data: {
            scheduleId: schedule.id,
            claimId,
            scheduledFireAt: schedule.nextFireAt,
            target: schedule.target,
          },
        });
        return;
      }
      default: {
        throw new Error(`Unsupported schedule target type: ${(schedule.target as { type: string }).type}`);
      }
    }
  }
}

/**
 * @deprecated Renamed to {@link Scheduler}. The scheduler now drives both
 * workflow and agent schedules, so the `Workflow`-prefixed name is no longer
 * accurate. This alias will be removed in a future major release.
 */
export const WorkflowScheduler = Scheduler;

/**
 * @deprecated Renamed to {@link Scheduler}. This alias will be removed in a
 * future major release.
 */
export type WorkflowScheduler = Scheduler;

View on GitHub (pinned to 75dd419e61)

Solutions

Print/inspect schedule.target.type and set it to one of the scheduler's supported target types.
Fix the typo in the target type discriminator.
Re-create the schedule through the scheduler's public API so it validates the target.
Migrate or delete stale persisted schedules written by incompatible versions.

Example fix

// before
scheduler.createSchedule({ target: { type: 'workflows', id: 'myFlow' } });
// after
scheduler.createSchedule({ target: { type: 'workflow', id: 'myFlow' } });

Defensive patterns

Strategy: validation

Validate before calling

const SUPPORTED_TARGET_TYPES = ['workflow','step','event']; // per scheduler docs
function assertTarget(t: { type: string }) {
  if (!SUPPORTED_TARGET_TYPES.includes(t.type)) throw new Error(`Unsupported schedule target type: ${t.type}`);
}

Type guard

function isSupportedTarget(t: unknown): t is { type: string; id: string } {
  const types = ['workflow','step','event'];
  return !!t && typeof t === 'object' && 'type' in t && types.includes((t as any).type);
}

Try / catch

try {
  scheduler.createSchedule({ target });
} catch (e) {
  if ((e as Error).message.startsWith('Unsupported schedule target type')) {
    console.error(`Target type '${target.type}' unsupported; allowed: workflow, step, event`);
  } else throw e;
}

Prevention

Create schedules only through the scheduler's public API, which validates targets
Use a discriminated-union TS type for schedule targets
Check persisted schedule records after upgrading library versions
Avoid hand-editing stored schedule state

When it happens

Trigger: Creating or persisting a schedule whose target.type is misspelled ('workflows' vs 'workflow'), added by a newer/older version, or comes from deserialized state written by a different schema version.

Common situations: Hand-edited persisted schedule records; version skew between the writer of the schedule and the scheduler process; custom target types that were never registered.

Related errors

AI-assisted analysis of mastra-ai/mastra@75dd419e61 (2026-08-30). Data as JSON: /api/errors/fd1038ccf6a1f8cf. Report an issue: GitHub.