Ragtime tries to run same migrations twice on Ubuntu 22.04

[akselikap]

I really don't know how to give you anything to go on but let's try.
We have a very basic setup, basically the one instructed in the documentation to use with Leiningen. This setup used to work on my PC ~4 months ago. I haven't touched the code at all nor the versions but now if I try to run "lein migrate" it crashes. I tested 2 scenarios and here are the results

Scenario 1 - Nothing in the database:
It tries to apply the first migration twice in a row resulting in a crash when creating something that can't be created twice. I can see the Applying 000-migration twice in a row and after that it crashes. Also I verified this using database logs.

Scenario 2 - Everything already in database and fully migrated
Conflict! Expected 000-migration but 001-migration was applied.

On a Macbook using same version of Leiningen and Java this operation works as expected. What's going on? 😕 We are using PostgreSQL if that's relevant here.

lein --version
Leiningen 2.9.10 on Java 1.8.0_342 OpenJDK 64-Bit Server VM
(I also tried Java 11 and same thing)

inxi -S
System:
Host: **** Kernel: 5.15.0-52-generic x86_64 bits: 64
Desktop: Unity Distro: Ubuntu 22.04.1 LTS (Jammy Jellyfish)

[akselikap]

I tested this a bit more and it seems like this line is the problem. The resauce call returns the same migration 4 times. 2 times from resources/migrations and 2 times from target/classes/migrations.

[akselikap]

I resolved the issue by using :migrations (jdbc/load-directory "resources/migrations") instead of :migrations (jdbc/load-resources "migrations")}). I guess there is a bug somewhere or maybe it's just in my system but this resolved this for me.

[restenb]

We ran into the same problem just now - the up migrations would be read in twice.

I believe this can happen when there are files with formats other than .sql or .edn in the migrations folder. I had accidentally fat-fingered a .clj file into the folder and didn't notice it. The .clj file ends up being loaded as well, and is not filtered out properly as an unsupported format, somehow causing the duplication of all migration files (so each migration would be duplicated as two up migrations, two down migrations). This then leads to the behaviour @akselikap described.

Deleting the rogue .clj file and starting with a clean build resolved the issue.