The sort on :applied in migratus.database/completed-ids* did not handle nil, meaning the presence of one or more migrations lacking an applied timestamp would cause it to break. Any sql migrations pre-0.9.1 will not have an applied value unless users have retroactively set it, and the schema allows NULLs, so migratus cannot assume applied is not nil.
The fix is simple because we have compare, which is essentially .compareTo-but-handles-nil. Any nil values will be sorted to the end, which is correct for the intended purpose here.
Current tests wouldn't catch this because they migrate up a database from scratch without legacy records. I have looked for a relevant test to update/add, but there's no integration test with an existing migrations table and it seems like a bunch of work to add one.
The sort on
:applied
inmigratus.database/completed-ids*
did not handle nil, meaning the presence of one or more migrations lacking anapplied
timestamp would cause it to break. Any sql migrations pre-0.9.1 will not have anapplied
value unless users have retroactively set it, and the schema allows NULLs, so migratus cannot assumeapplied
is not nil.The fix is simple because we have
compare
, which is essentially.compareTo
-but-handles-nil. Any nil values will be sorted to the end, which is correct for the intended purpose here.Current tests wouldn't catch this because they migrate up a database from scratch without legacy records. I have looked for a relevant test to update/add, but there's no integration test with an existing migrations table and it seems like a bunch of work to add one.