ory/hydra · error

migrations have not yet been fully applied: %+v

Error message

migrations have not yet been fully applied: %+v

What it means

During registry initialization Hydra checks migration status (PopMiscMigrations/ValidateMigrations path in registry_sql.go). If any migration for the connection has a state other than "Applied", it errors with the list of unapplied versions and logs a warning that the instance is not yet ready. This prevents running a code version against a database schema it doesn't match.

Source

Thrown at driver/registry_sql.go:398

	if m.hh == nil {
		m.hh = healthx.NewHandler(m.Writer(), config.Version, healthx.ReadyCheckers{
			"database": func(r *http.Request) error {
				return m.PingContext(r.Context())
			},
			"migrations": func(r *http.Request) error {
				status, err := m.migrator.MigrationStatus(r.Context())
				if err != nil {
					return err
				}

				if status.HasPending() {
					var notApplied []string
					for _, s := range status {
						if s.State != "Applied" {
							notApplied = append(notApplied, s.Version)
						}
					}
					err := errors.Errorf("migrations have not yet been fully applied: %+v", notApplied)
					m.Logger().WithField("not_applied", fmt.Sprintf("%+v", notApplied)).WithError(err).Warn("Instance is not yet ready because migrations have not yet been fully applied.")
					return err
				}
				return nil
			},
		})
	}

	return m.hh
}

func (m *RegistrySQL) ConsentStrategy() consent.Strategy {
	if m.cos == nil {
		m.cos = consent.NewStrategy(m)
	}
	return m.cos
}

View on GitHub (pinned to 4174065ffb)

Solutions

  1. Run `hydra migrate sql up -e "$DSN"` to apply pending migrations, then restart the instance.
  2. Check status with `hydra migrate sql status -e "$DSN"` to see which versions are not Applied.
  3. If a migration failed midway, fix the underlying DB issue (permissions, locks) and re-run; check for partially applied transactions.
  4. Ensure your deployment pipeline runs migrations as a pre-deploy step before rolling out new Hydra binaries.

Example fix

// before (CI)
- docker run oryd/hydra:v2.2.0 serve all

// after (CI)
- docker run oryd/hydra:v2.2.0 migrate sql up -e "$DSN"
- docker run oryd/hydra:v2.2.0 serve all
Defensive patterns

Strategy: validation

Validate before calling

// gate deployment on migration status
out, err := exec.Command("hydra", "migrate", "sql", "status", "-e", dsn).Output()
if err != nil || strings.Contains(string(out), "Pending") {
    return fmt.Errorf("run `hydra migrate sql up` before starting hydra")
}

Try / catch

if err := hydra.Start(ctx); err != nil {
    if strings.Contains(err.Error(), "migrations have not yet been fully applied") {
        log.Println("running pending migrations...")
        if err := hydra.MigrateUp(ctx, dsn); err != nil {
            log.Fatalf("migration failed: %+v", err)
        }
        return hydra.Start(ctx)
    }
    log.Fatalf("hydra failed: %+v", err)
}

Prevention

When it happens

Trigger: Starting `hydra serve` (or any registry boot that runs the migration readiness check) when `hydra migrate sql` has not been run for the current code version — the schemamigration status returns pending/missing versions.

Common situations: Deploying a new Hydra version without running migrations first; running multiple Hydra replicas where one applied migrations late; manually skipping `hydra migrate sql up` in CI/CD; partial migration failure leaving a version in a non-Applied state.

Related errors


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