windmill-labs/windmill · warning

Failed to run new datatable migrations: ${e?.body ?? e?.mess

Error message

Failed to run new datatable migrations: ${e?.body ?? e?.message ?? e}

What it means

After a push that introduced new datatable store usage, the CLI offers/accepts to run pending datatable migrations server-side via offerToRunNewMigrations. If that call throws (API error, user denial path error, network), the failure is logged as a warning with the error body/message rather than aborting the push, which has already completed.

Source

Thrown at cli/src/commands/sync/sync.ts:6537

        await Promise.race(pool);
      }
    }
    try {
      await pushSharedUi(workspace.workspaceId, opts.keepDeleted);
    } catch (e) {
      log.warn(`Failed to push shared UI folder: ${e}`);
    }
    try {
      await offerToRunNewMigrations(
        workspace.workspaceId,
        newDatatableMigrations,
        {
          yes: opts.yes,
          jsonOutput: opts.jsonOutput,
        },
      );
    } catch (e: any) {
      log.warn(
        `Failed to run new datatable migrations: ${e?.body ?? e?.message ?? e}`,
      );
    }
    const lockJobs = await checkServerLockJobs(
      workspace.workspaceId,
      pushStartedAt,
      changes.map((c) => c.path.replaceAll(SEP, "/")),
    );
    if (!opts.jsonOutput) {
      for (const f of lockJobs.failed) {
        log.warn(
          `⚠ server-side lock generation FAILED for ${f.path} — the deployed script is broken until it locks.` +
            (f.error ? `\n  ${f.error.split("\n")[0]}` : ""),
        );
      }
      if (lockJobs.pending > 0) {
        log.info(
          colors.gray(

View on GitHub (pinned to e474e8803c)

Solutions

1. Run the migrations explicitly: check the workspace's datatable settings in the UI or use the dedicated migration command, then re-push.
2. Check the interpolated error body for the server-side reason (e.g. permission denied, migration conflict).
3. Retry the push once the server is healthy — migration execution is idempotent per migration.

Example fix

// before
wmill sync push  # migrations fail silently as warning
// after
# apply pending migrations first (UI: workspace settings → datatables), then
wmill sync push

// Before push, check pending migrations and permissions:
const stores = await wmill.listDatatableStores({ workspace });
const pending = stores.filter((s) => s.migrationsPending);
if (pending.length > 0) console.log('Run migrations first:', pending.map((s) => s.name));

function hasMigrationError(e: unknown): e is { body?: { message?: string }; message?: string } {
  return typeof e === 'object' && e !== null;
}

try {
  await offerToRunNewMigrations(workspaceId, migrations, opts);
} catch (e: any) {
  log.warn(`Migrations not run: ${e?.body ?? e?.message ?? e}`);
  // retry via UI/datatable settings before next push
}

When it happens

Trigger: `wmill sync push` detects new datatable migrations to run, invokes offerToRunNewMigrations, and the migration-triggering API call fails (HTTP 4xx/5xx, network, invalid migration state) or the error lacks body/message.

Common situations: Pushing scripts bound to a datatable whose server-side migrations are pending but fail to start; insufficient permission to run migrations; server busy/unreachable at end of push.

Related errors

• Datatable '${dtName}' already exists in this workspace
• Workspace already has datatable(s): ${existing.map((d) => d.
• Invalid migration name '${name}': use only letters, digits,
• Workspace folder not found, are you in the right directory?
• Not a fileset resource path: ${changePath}

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