buffalo pop migrate only read the timestamp in migration file name

[GaelFG]

Description

If two migration file (file ending by up.fizz while generated by buffalo resource create) happen to begin with the same timestamp, even if the end of the file name and their content differ, only the first file migration is run, but the second file migration is tagged as 'done' in the 'buffalo pop migrate status' command.

It happened to me because a generate a bunch of resources nearly simultaneaously using a script.

Even if it has more chances to happen using buffalo, I tagged it as a pop unexpected behavior

Steps to Reproduce the Problem

1. I wrote a shell script creating a lot (around 30) of resources with model definitions, simplified exemple :
   generate_ressources.sh :
   buffalo generate resource item1 guid:uuid.UUID attr:string attr2:time.Time attr3:time.Time
   buffalo generate resource item2 guid:uuid.UUID attr:string attr2:time.Time attr3:time.Time
   buffalo generate resource item3 guid:uuid.UUID attr:string attr2:time.Time attr3:time.Time
   buffalo generate resource item4 guid:uuid.UUID attr:string attr2:time.Time attr3:time.Time
   buffalo generate resource item5 guid:uuid.UUID attr:string attr2:time.Time attr3:time.Time
   buffalo generate resource item6 guid:uuid.UUID attr:string attr2:time.Time attr3:time.Time
   buffalo generate resource item7 guid:uuid.UUID attr:string attr2:time.Time attr3:time.Time
   buffalo generate resource item8 guid:uuid.UUID attr:string attr2:time.Time attr3:time.Time
   buffalo generate resource item9 guid:uuid.UUID attr:string attr2:time.Time attr3:time.Time
   buffalo generate resource item10 guid:uuid.UUID attr:string attr2:time.Time attr3:time.Time
   buffalo generate resource item11 guid:uuid.UUID attr:string attr2:time.Time attr3:time.Time
   buffalo generate resource item12 guid:uuid.UUID attr:string attr2:time.Time attr3:time.Time
   etc ...

2. I executed the script.

Note : I think the cause of the error is here. the generated file begin with a timestamp. Since I'm running the generations via scripting, it happened sometime 2 resources have the same timestamp as begining of their filename. The end do differ and include the name I gave to my resource.

3. I ran 'buffalo pop create -a'

4. I ran 'buffalo pop migrate'

5. While checking the database via my application or dorectly via pgadmin

Expected Behavior

If possible, all migration scripts should have been happlied.
At least, unaplied migrations scripts should not have been tagged as applied, and an error message specifying something like 'Warning, you have two migration scripts sharing the same ID, only the first will be applied' :)

Actual Behavior

There was no error message, but some tables were not created. In the log, I could see the tables were not created, but doing 'buffalo pop status' show the non executed migrations as having been done.

Info

Stated on Windows10, using built in pop version of buffalo :

relevant lines in go.mod :

go 1.14
github.com/gobuffalo/buffalo v0.15.5
github.com/gobuffalo/buffalo-pop/v2 v2.0.6
github.com/gobuffalo/pop/v5 v5.1.1

In case that's relevant I was using a local postgresql database.

Current analysis

After some trial and error, it seems to me the problem was the files of somes migration began with the same id, generated from a timestamp.
If i change the timestamp in the file name, the migration work as intended.

It's not a critical bug, and it happened because I use a particular workflow (I assume most people don't write a generator script) but I still thinks it's not logical and not documented that only the number in the begining of the filename is used to identify a migration step.

Edit

Corrected the exemple script provided (it contained a typo)

[ayuayue]

try Change timestamp to time.Time

[GaelFG]

My exemple script in the bug report indeed contained a typo (unrelated to the bug), thanks for pointing it out :)

[sio4]

Indeed, that can happen since the timestamp on the file is just second precision. Yeah, as you said it will not usually happen, and very far edge case.

Anyway, could you please explain why your workflow runs the buffalo g command in a batch if possible? I wonder when it is needed and want to learn about your experience.