What causes "error executing %s, sql: %s" in ory/hydra?

Read the wrapped driver error and the included SQL to find the failing statement; fix the migration SQL

error executing %s, sql: %s

Error message

error executing %s, sql: %s

What it means

When executing a migration's SQL against the database (via queryExecutor Exec, using the transaction or the raw SQL DB), any driver error is wrapped as "error executing <path>, sql: <content>" (oryx/popx/migration_box.go:209). This exposes both the failing migration file and its SQL so the database-level error can be diagnosed.

Source

Thrown at oryx/popx/migration_box.go:209

	txRunner := func(b []byte) func(Migration, *pop.Connection) error {
		return func(mf Migration, c *pop.Connection) error {
			content, err := mb.migrationContent(mf, c, b, true)
			if err != nil {
				return errors.Wrapf(err, "error processing %s", mf.Path)
			}
			if isMigrationEmpty(content) {
				l.WithField("migration", mf.Path).Trace("This is usually ok - ignoring migration because content is empty. This is ok!")
				return nil
			}

			var q queryExecutor = c.Store.SQLDB()
			if c.TX != nil {
				q = c.TX
			}

			if _, err = q.Exec(content); err != nil {
				return errors.Wrapf(err, "error executing %s, sql: %s", mf.Path, content)
			}
			return nil
		}
	}

	err := mb.findMigrations(dir, txRunner)
	if err != nil {
		return mb, err
	}

	if err := mb.check(); err != nil {
		return nil, err
	}
	return mb, nil
}

// migrationFallbacks returns the ordered dialects migration selection falls
// back to before the generic ("all") file (.yugabyte. → .postgres. → generic

View on GitHub (pinned to 4174065ffb)

Solutions

Read the wrapped driver error and the included SQL to find the failing statement; fix the migration SQL
Restore the database to a consistent state (drop partially created objects or restore a snapshot) before retrying
Run the migration with the .autocommit flag / correct dialect if it performs DDL that cannot run in a transaction
Check the database user has sufficient privileges

Example fix

-- before (fails on re-run)
CREATE TABLE users (id serial primary key);
-- after (idempotent)
CREATE TABLE IF NOT EXISTS users (id serial primary key);

Defensive patterns

Strategy: try-catch

Validate before calling

// dry-run the statement's shape on a dev database with the same engine and version
if err := conn.RawQuery("SELECT 1").Exec(); err != nil { return err } // connectivity/privilege sanity check

Try / catch

err := mb.Exec(ctx, conn)
var path, sql string
if err != nil {
    fmt.Printf("%+v\n", err) // shows 'error executing <path>, sql: <content>' + driver cause
    return err
}

Prevention

Write idempotent SQL (IF NOT EXISTS / IF EXISTS) so retried migrations succeed
Run migrations in CI against the same database engine/version as production
Ensure the migration user has DDL privileges
Use .autocommit for DDL on dialects that cannot run DDL in transactions (CockroachDB, MySQL, YugabyteDB)
Back up the database before applying migrations

When it happens

Trigger: q.Exec(content) fails while running migrations — e.g. syntax error, permission denied, object already exists, or a DDL statement incompatible with the dialect/transaction mode.

Common situations: Re-running a partially applied migration (table already exists); insufficient database user privileges; SQL valid in Postgres but invalid in CockroachDB/MySQL; non-transactional DDL on dialects requiring autocommit.

Related errors

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