ory/hydra · error

%s

Error message

%s

What it means

When parsing a migration filename, parseMigrationFilename canonicalizes the dialect segment and rejects dialects the build does not support (oryx/popx/match.go:74). It wraps errUnsupportedMigrationDialect ("unsupported dialect") with the offending dialect name via errors.Wrapf, so the rendered message is just the dialect string. This prevents migrations written for unregistered dialects from being loaded.

Source

Thrown at oryx/popx/match.go:75

		// A special case where autocommit group moves forward to the 3rd index.
		autocommit = true
		dbType = "all"
	} else if m[dbTypeIdx] == "" {
		dbType = "all"
	} else {
		dbType = strings.TrimPrefix(m[dbTypeIdx], ".")
		// The commercial package registers this dialect from init(), but
		// migration boxes can be constructed before that package enters the
		// import graph. Canonicalize both accepted spellings independently of
		// registration so migration selection is deterministic in every build.
		switch dbType {
		case dbal.DriverYugabyteDB, "yugabytedb":
			dbType = dbal.DriverYugabyteDB
		default:
			dbType = pop.CanonicalDialect(dbType)
		}
		if dbType != dbal.DriverYugabyteDB && !pop.DialectSupported(dbType) {
			return nil, errors.Wrapf(errUnsupportedMigrationDialect, "%s", dbType)
		}
	}

	if m[typeIdx] == "fizz" && dbType != "all" {
		return nil, errors.Errorf("invalid database type %q, expected \"all\" because fizz is database type independent", dbType)
	}

	if m[autocommitIdx] == ".autocommit" {
		autocommit = true
	} else if m[autocommitIdx] != "" {
		return nil, errors.Errorf("invalid autocommit flag %q", m[autocommitIdx])
	}

	return &match{
		Version:    m[versionIdx],
		Name:       m[nameIdx],
		DBType:     dbType,
		Autocommit: autocommit,

View on GitHub (pinned to 4174065ffb)

Solutions

1. Fix the dialect segment in the migration filename to a supported one (postgres, cockroach, mysql, sqlite3, all)
2. Ensure the package that registers the dialect is imported into the binary's import graph
3. Check for typos in the filename dialect segment

Example fix

// before (unsupported/typo'd dialect)
20210101000000_add_table.posgres.up.sql
// after
20210101000000_add_table.postgres.up.sql

re := regexp.MustCompile(`^(\d+)_([^.]+)(\.[a-z0-9]+)?(\.autocommit)?\.(up|down)\.(sql)$`)
if !re.MatchString(filename) { return fmt.Errorf("bad migration filename %q", filename) }
dialect := extractDialect(filename)
if !pop.DialectSupported(dialect) { return fmt.Errorf("unsupported dialect %q in %q", dialect, filename) }

m, err := parseMigrationFilename(name)
if err != nil {
    var wrapped interface{ Cause() error }
    if errors.As(err, &cause) && errors.Is(cause, errUnsupportedMigrationDialect) { /* skip or fix */ }
    return err
}

When it happens

Trigger: A migration file like 20210101000000_name.pgsql.up.sql (or any dialect segment) whose dbType, after canonicalization, is not YugabyteDB and fails pop.DialectSupported(dbType) — e.g. a dialect never registered (no driver import or commercial init()) or a typo in the dialect segment.

Common situations: Embedding migration files from a project that targets a dialect the consuming binary does not import; forgetting to import the enterprise package that registers yugabyte/yugabytedb (though those are canonicalized unconditionally); typos like .posgres. or .mysqlite. in filenames.

Related errors

• unsupported dialect
• invalid database type %q, expected "all" because fizz is dat
• invalid autocommit flag %q
• Found a migration file that does not match the file pattern:
• unknown migration direction %q for %q

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