`create -seq` cli command produces wrong migration number

Author: 42LMCreated Jun 17, 2024Updated Sep 9, 2026

First of all thanks for making this great library <3.

Describe the Bug The create cli command produces the wrong migration number.

Command used:

bash

migrate create -dir ./migrations -seq -digits 2 -ext sql foobar
error: duplicate migration version: 10

The /migrations folder contains the following files:

0_.down.sql
0_.up.sql
1_.down.sql
1_.up.sql
2_.down.sql
2_.up.sql
3_.down.sql
3_.up.sql
4_.down.sql
4_.up.sql
5_.down.sql
5_.up.sql
6_.down.sql
6_.up.sql
7_.down.sql
7_.up.sql
8_.down.sql
8_.up.sql
9_.down.sql
9_.up.sql
10_.down.sql
10_.up.sql
11_.down.sql
11_.up.sql

Steps to Reproduce Steps to reproduce the behavior:

Create an example project with a /migrations folder somewhat like the following:

.
└── migrations
 ├── 0_.down.sql
 ├── 0_.up.sql
 ├── 1_.down.sql
 ├── 1_.up.sql
 ├── 2_.down.sql
 ├── 2_.up.sql
 ├── 3_.down.sql
 ├── 3_.up.sql
 ├── 4_.down.sql
 ├── 4_.up.sql
 ├── 5_.down.sql
 ├── 5_.up.sql
 ├── 6_.down.sql
 ├── 6_.up.sql
 ├── 7_.down.sql
 ├── 7_.up.sql
 ├── 8_.down.sql
 ├── 8_.up.sql
 ├── 9_.down.sql
 ├── 9_.up.sql
 ├── 10_.down.sql
 ├── 10_.up.sql
 ├── 11_.down.sql
 └── 11_.up.sql

Run the migrate create cli command with the option to generate sequential up/down migrations with N digits: migrate create -dir ./migrations -seq -digits 2 -ext sql foobar
See error

bash

~/go/src/migratetest
migrate create -dir ./migrations -seq -digits 2 -ext sql foobar
error: duplicate migration version: 10

Expected Behavior The migrate create cli command does not raise an error, instead it creates the files 12_foobar.up.sql and 12_foobar.down.sql.

Migrate Version v4.17.1

Loaded Source Drivers (Should not matter)

bitbucket, godoc-vfs, s3, gcs, file, github, github-ee, gitlab, go-bindata

Loaded Database Drivers (Should not matter)

Database drivers: pgx4, yugabytedb, firebird, mongodb+srv, stub, cockroach, crdb-postgres, pgx, redshift, yugabyte, cassandra, pgx5, cockroachdb, postgresql, mongodb, sqlserver, spanner, mysql, ysql, firebirdsql, rqlite, clickhouse, postgres, neo4j

Go Version go version go1.22.2 darwin/arm64

Stacktrace

Additional context The matches obtained in the create cli Command in line 87:

https://github.com/golang-migrate/migrate/blob/2477f639fdba30c69a3b2dee3c788d4877cb2e97/internal/cli/commands.go#L87

results in the slice:

[]string{
    "migrations/0_.down.sql",
    "migrations/0_.up.sql",
    "migrations/10_.down.sql",
    "migrations/10_.up.sql",
    "migrations/11_.down.sql",
    "migrations/11_.up.sql",
    "migrations/1_.down.sql",
    "migrations/1_.up.sql",
    "migrations/2_.down.sql",
    "migrations/2_.up.sql",
    "migrations/3_.down.sql",
    "migrations/3_.up.sql",
    "migrations/4_.down.sql",
    "migrations/4_.up.sql",
    "migrations/5_.down.sql",
    "migrations/5_.up.sql",
    "migrations/6_.down.sql",
    "migrations/6_.up.sql",
    "migrations/7_.down.sql",
    "migrations/7_.up.sql",
    "migrations/8_.down.sql",
    "migrations/8_.up.sql",
    "migrations/9_.down.sql",
    "migrations/9_.up.sql",
}

When nextSeqVersion is used to obtain the next version number it takes the last element of the slice in line 31:

https://github.com/golang-migrate/migrate/blob/2477f639fdba30c69a3b2dee3c788d4877cb2e97/internal/cli/commands.go#L31

and this results in the new version number being determined as 10, which in this case is not correct.

PS: Everyone have a great week.

Source: golang-migrate/migrate

View original on GitHub View discussion on GitHub