Panic when using cli migration

[nathankawalec]

I'm running into a panic when using the command:

river migrate-up --database-url postgres://host:5432/db

The stack trace is:

PS C:\Users\Nathan\source\voicelab\voicelab.ai\voicelab-api> river migrate-up --database-url postgres://host:5432/db  
panic: runtime error: slice bounds out of range [5:4]

goroutine 1 [running]:
github.com/riverqueue/river/rivermigrate.migrationsFromFS.func1({0xc00010d080, 0xe}, {0x0?, 0x0?}, {0x0?, 0x0?})
        C:/Users/Nathan/go/pkg/mod/github.com/riverqueue/river@v0.10.1/rivermigrate/river_migrate.go:596 +0x9a6
io/fs.walkDir({0xb50f80, 0xb65ee0}, {0xc00010d080, 0xe}, {0xb57c98, 0xb65f28}, 0xc000139950)
        C:/Program Files/Go/src/io/fs/walk.go:73 +0x6c
io/fs.walkDir({0xb50f80, 0xb65ee0}, {0xa66e5f, 0x9}, {0xb57ad8, 0xc00010a7c0}, 0xc000139950)
        C:/Program Files/Go/src/io/fs/walk.go:95 +0x2bf
io/fs.WalkDir({0xb50f80, 0xb65ee0}, {0xa66e5f, 0x9}, 0xc000139950)
        C:/Program Files/Go/src/io/fs/walk.go:122 +0xa5
github.com/riverqueue/river/rivermigrate.migrationsFromFS({0xb50f80?, 0xb65ee0?}, {0xa6514e, 0x4})
        C:/Users/Nathan/go/pkg/mod/github.com/riverqueue/river@v0.10.1/rivermigrate/river_migrate.go:573 +0xbd
github.com/riverqueue/river/rivermigrate.New[...]({0xb5b650, 0xc00010e150}, 0x1)
        C:/Users/Nathan/go/pkg/mod/github.com/riverqueue/river@v0.10.1/rivermigrate/river_migrate.go:122 +0x333
github.com/riverqueue/river/cmd/river/rivercli.RunCommand[...].func1.4()
        C:/Users/Nathan/go/pkg/mod/github.com/riverqueue/river/cmd/river@v0.10.1/rivercli/command.go:103 +0x25
github.com/riverqueue/river/cmd/river/rivercli.(*migrateUp).Run(0xc00011e8c0, {0xb57710, 0xffdc60}, 0xc00011e780)
        C:/Users/Nathan/go/pkg/mod/github.com/riverqueue/river/cmd/river@v0.10.1/rivercli/river_cli.go:458 +0x7e
github.com/riverqueue/river/cmd/river/rivercli.RunCommand[...].func1()
        C:/Users/Nathan/go/pkg/mod/github.com/riverqueue/river/cmd/river@v0.10.1/rivercli/command.go:111 +0x418
github.com/riverqueue/river/cmd/river/rivercli.RunCommand[...]({0xb57710?, 0xffdc60?}, 0x0?, {0xb53be8?, 0xc00011e8c0?}, 0xf46db13b00000000?)
        C:/Users/Nathan/go/pkg/mod/github.com/riverqueue/river/cmd/river@v0.10.1/rivercli/command.go:114 +0x90
github.com/riverqueue/river/cmd/river/rivercli.(*CLI).BaseCommandSet.func11(0xc000186900?, {0xa652fa?, 0x4?, 0xa65262?})
        C:/Users/Nathan/go/pkg/mod/github.com/riverqueue/river/cmd/river@v0.10.1/rivercli/river_cli.go:236 +0x70
github.com/spf13/cobra.(*Command).execute(0xc000198f08, {0xc000118b40, 0x2, 0x2})
        C:/Users/Nathan/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:987 +0xab1
github.com/spf13/cobra.(*Command).ExecuteC(0xc000198308)
        C:/Users/Nathan/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1115 +0x3ff
github.com/spf13/cobra.(*Command).Execute(0xc00010a450?)
        C:/Users/Nathan/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1039 +0x13
main.main()
        C:/Users/Nathan/go/pkg/mod/github.com/riverqueue/river/cmd/river@v0.10.1/main.go:23 +0x3a

Using Go version: 1.22.5 Postgresql version: 16.3 Os: Windows 10 Home

I will retry on linux to see if the problem persists.

[brandur]

Thanks for the report. 99% chance it's a Windows-specific problem. Apparently file paths behave differently. I'll have to look into it.

[bgentry]

I suspect it's because of this:

The patterns are interpreted relative to the package directory containing the source file. The path separator is a forward slash, even on Windows systems.

But then filepath.Join uses OS-specific separators:

The filepath package uses either forward slashes or backslashes, depending on the operating system. To process paths such as URLs that always use forward slashes regardless of the operating system, see the path package.

So I think we need to update any bits in the migration embedded FS reading code to use regular path and not filepath, including this bit:

https://github.com/riverqueue/river/blob/280896e5063bc014ba83229a4c00b24d9c1ca7a4/rivermigrate/river_migrate.go#L578-L581

[nathankawalec]

Yeah, seems likely that it's a windows issue. It's working fine on Ubuntu. Unfortunately, I work on Windows...

[brandur]

Yep, great point on filepath. Actually it turns out that if we remove its use, the code gets considerably cleaned up anyway ... Opened #485.