ory/hydra · error

problem checking for migration version %s

Error message

problem checking for migration version %s

What it means

Before applying a migration, UpTo checks the schema_migrations table for the version (and its legacy 14-char-truncated variant). If the raw query fails, the error is wrapped with 'problem checking for migration version %s', naming the migration version being checked.

Source

Thrown at oryx/popx/migrator.go:202

	}

	// Keep applied across whole-run retry attempts. Every migration counted here
	// has already committed its schema_migration row, so it remains part of this
	// UpTo call's step budget even when a later migration retries.
	err = mb.exec(ctx, func() error {
		mtn := sanitizedMigrationTableName(c)
		mfs := mb.migrationsUp.sortAndFilter(mb.c.Dialect.Name(), mb.migrationFallbacks()...)
		for _, mi := range mfs {
			l := mb.l.WithField("version", mi.Version).WithField("migration_name", mi.Name).WithField("migration_file", mi.Path)

			appliedMigrations := make([]string, 0, 2)
			legacyVersion := mi.Version
			if len(legacyVersion) > 14 {
				legacyVersion = legacyVersion[:14]
			}
			err := c.RawQuery(fmt.Sprintf("SELECT version FROM %s WHERE version IN (?, ?)", mtn), mi.Version, legacyVersion).All(&appliedMigrations)
			if err != nil {
				return errors.Wrapf(err, "problem checking for migration version %s", mi.Version)
			}

			if slices.Contains(appliedMigrations, mi.Version) {
				l.Debug("Migration has already been applied, skipping.")
				continue
			}

			if slices.Contains(appliedMigrations, legacyVersion) {
				l.WithField("legacy_version", legacyVersion).WithField("migration_table", mtn).Debug("Migration has already been applied in a legacy migration run. Updating version in migration table.")
				if err := mb.isolatedTransaction(ctx, "init-migrate", func(conn *pop.Connection) error {
					// We do not want to remove the legacy migration version or subsequent migrations might be applied twice.
					//
					// Do not activate the following - it is just for reference.
					//
					// if _, err := tx.Store.Exec(fmt.Sprintf("DELETE FROM %s WHERE version = ?", mtn), legacyVersion); err != nil {
					//	return errors.Wrapf(err, "problem removing legacy version %s", mi.Version)
					// }

View on GitHub (pinned to 4174065ffb)

Solutions

  1. Verify the schema_migrations table exists (run the library's migration init/create command)
  2. Check the DB user has SELECT privileges on the migrations table
  3. Inspect the wrapped cause for connection/dialect-specific errors
  4. Recreate a corrupted migrations table from the library's expected schema

Example fix

// before
psql -U app -d db -c "SELECT * FROM schema_migrations" -- permission denied
// after
GRANT SELECT ON schema_migrations TO app;
Defensive patterns

Strategy: try-catch

Validate before calling

// Verify migrations table exists and is readable before running migrations
exists, err := tableExists(db, "schema_migrations")
if err != nil { return err }
if !exists {
  return errors.New("schema_migrations table missing; run migration init first")
}

Try / catch

if err := mb.UpTo(ctx, -1); err != nil {
  if strings.Contains(err.Error(), "problem checking for migration version") {
    // inspect wrapped cause; possibly re-init migrations table
    log.Printf("version check failed: %v", errors.Unwrap(err))
  }
  return err
}

Prevention

When it happens

Trigger: SELECT version FROM <schema_migrations> fails — table missing (fresh DB where creation failed), wrong dialect SQL, permissions denied, or connection error during the query.

Common situations: Migrations table dropped manually; running against a database user lacking SELECT privileges; DB connection dropped mid-run; schema_migrations table created by a different tool with a different schema.

Related errors


AI-assisted analysis of ory/hydra@4174065ffb (2026-09-03). Data as JSON: /api/errors/6d55ab2b03aa92fc. Report an issue: GitHub.