mastra-ai/mastra · error · Error

Database was ${db.status === 'deleted' ? 'deleted' : 'schedu

Error message

Database was ${db.status === 'deleted' ? 'deleted' : 'scheduled for deletion'} while provisioning

What it means

While pollDatabaseUntilReady waits for a newly created database to become 'ready', the platform can report the database as 'deleting' or 'deleted'. The CLI treats this as a terminal condition and throws, wording the message based on which of the two statuses was observed ('deleted' vs 'scheduled for deletion'). It means the database vanished mid-provisioning, typically due to a concurrent delete or a server-side lifecycle action.

Source

Thrown at packages/cli/src/commands/db/platform-api.ts:214

  while (true) {
    const db = await withPollingRetries(() => fetchDatabase(token, orgId, projectId, dbId));

    if (db.status !== lastStatus) {
      lastStatus = db.status;
      opts?.onStatus?.(db.status);
    }

    if (db.status === 'ready') {
      return db;
    }

    if (db.status === 'failed') {
      throw new Error(`Database provisioning failed${db.error ? `: ${db.error}` : ' (no error detail from provider)'}`);
    }

    if (db.status === 'deleting' || db.status === 'deleted') {
      throw new Error(
        `Database was ${db.status === 'deleted' ? 'deleted' : 'scheduled for deletion'} while provisioning`,
      );
    }

    if (Date.now() - start >= maxWaitMs) {
      throw new Error(
        `Timed out waiting for database to become ready (last status: ${db.status}). ` +
          `Check again with: mastra env db show ${dbId}`,
      );
    }

    await new Promise(resolve => setTimeout(resolve, intervalMs));
  }
}

View on GitHub (pinned to 75dd419e61)

Solutions

  1. Check with `mastra env db show <dbId>` to confirm the database's actual state
  2. Verify no teammate/script is deleting the same database concurrently
  3. Re-run `mastra env db create` to provision a fresh database
  4. If deletions recur unexpectedly, audit org automation tokens and delete hooks

Example fix

// before
// script A: createDatabase(...); script B: deleteDatabase(dbId) — poll sees 'deleting'
// after
// serialize operations: run delete first, await completion, then createDatabase(...)
Defensive patterns

Strategy: try-catch

Validate before calling

// Guard against concurrent deletes: check state immediately before create
const existing = await fetchDatabase(token, orgId, projectId, dbId).catch(() => null);
if (existing && ['deleting','deleted'].includes(existing.status)) {
  throw new Error('Database is being deleted; wait and re-create');
}

Type guard

function isVanishedDuringProvisioning(db: { status: string }): boolean {
  return db.status === 'deleting' || db.status === 'deleted';
}

Try / catch

try {
  const db = await createDatabase(opts);
} catch (err) {
  if (err instanceof Error && /while provisioning$/.test(err.message)) {
    // safe to re-create a fresh database after confirming no concurrent deleter
  } else throw err;
}

Prevention

When it happens

Trigger: createDatabase -> pollDatabaseUntilReady sees db.status === 'deleting' or 'deleted' before the database ever reaches 'ready' — e.g., another operator or process issued a delete on the same database resource during the provisioning window.

Common situations: Two developers or a CI pipeline and a human both creating/deleting the same named database; a stale script deleting databases in the org; provider reaping failed/abandoned resources.

Related errors


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