windmill-labs/windmill · error

Datatable migration ${path} not found in ${workspaceFrom}

Error message

Datatable migration ${path} not found in ${workspaceFrom}

What it means

During a workspace-to-workspace deploy, deployItem looks up a datatable migration in the source workspace by (datatable, timestamp) before upserting it into the target. If no migration with that timestamp exists on the source datatable, it throws `Datatable migration <path> not found in <workspaceFrom>`. The local migration file or path references a migration that was deleted or never deployed to the source workspace.

Source

Thrown at cli/windmill-utils-internal/src/deploy.ts:760

          requestBody,
        });
      }
    } else if (kind === "datatable_migration") {
      const { datatable, timestamp } = parseDatatableMigrationDeployPath(path);
      const migrations = await provider.listDatatableMigrations({
        workspace: workspaceFrom,
      });
      const migration = (
        migrations as {
          datatable: string;
          timestamp: number;
          name: string;
          code_up: string;
          code_down?: string;
        }[]
      ).find((m) => m.datatable === datatable && m.timestamp === timestamp);
      if (!migration) {
        throw new Error(
          `Datatable migration ${path} not found in ${workspaceFrom}`
        );
      }
      try {
        await provider.upsertDatatableMigration({
          workspace: workspaceTo,
          datatableName: datatable,
          requestBody: {
            timestamp: migration.timestamp,
            name: migration.name,
            code_up: migration.code_up,
            ...(migration.code_down != null
              ? { code_down: migration.code_down }
              : {}),
          },
        });
      } catch (e) {
        throw asMigrationsDisabledError(e, datatable);

View on GitHub (pinned to e474e8803c)

Solutions

  1. Verify the migration exists in the source workspace (`wmill` datatable migration list / API) and correct workspaceFrom if wrong
  2. Re-push the missing migration to the source workspace first, then deploy
  3. Regenerate the migration locally so its timestamp matches one deployed on the source
  4. If the migration is genuinely obsolete, remove it from the deploy set

Example fix

// before
deployItem({ kind: "datatable_migration", path: "my_table/1726012345_create_users", workspaceFrom: "staging", ... })

// after
// ensure staging has it first, or point at the workspace that does:
deployItem({ kind: "datatable_migration", path: "my_table/1726012345_create_users", workspaceFrom: "dev", ... })
Defensive patterns

Strategy: validation

Validate before calling

const exists = await provider.checkItemExists?.({ kind: 'datatable_migration', workspace: workspaceFrom, path })
  ?? (await listMigrations(workspaceFrom, datatable)).some(m => m.timestamp === timestamp);
if (!exists) throw new Error(`Migration ${path} missing in ${workspaceFrom}; deploy it there first`);

Try / catch

const r = await deployItem({ kind: 'datatable_migration', path, workspaceFrom, workspaceTo });
if (!r.success && r.error?.includes('not found in')) {
  console.error(`Deploy ${path} to ${workspaceFrom} first, then retry`);
}

Prevention

When it happens

Trigger: Calling deployItem to copy a datatable_migration whose (datatable, timestamp) pair does not exist in the source workspace — e.g. the migration was archived/deleted upstream, the timestamp in the local file differs from what is deployed, or workspaceFrom is the wrong workspace.

Common situations: Promoting migrations between dev→staging where dev's migration was re-scaffolded with a new timestamp; the source workspace's datatable was recreated so its migrations reset; copy-pasting migration files between projects with divergent timestamps.

Related errors


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