up following an up -allow-missing had unexpected behaviour

[jonseymour]

I had a situation where a database had migrations 284, 286, 287 and 288 applied in that order but 285 was missing.

Then migration 285 appeared and needed to be applied. up without -allow-missing failed (as expected). up with -allow-missing succeeded (as expected).

My expectation was that if I ran up again, it would report no migrations to be applied because the sequence 284 -> 288 was now complete.

What actually happened was the goose tried to apply migration 286 again. This was not expected behaviour (at least to me).

It seems that goose is assuming the next version to be applied is the successor of the version with the highest id sequence number, irrespective of whether there are already migrations with that version number already applied (as per https://github.com/pressly/goose/blob/v3.7.0/dialect.go#L71)

I worked around it with sql like this:

insert into goose_db_version (version_id, is_applied, tstamp) (select version_id+1, is_applied, tstamp from goose_db_version where version_id = 288);
delete from goose_db_version where version_id = 288;
update goose_db_version set version_id = 288 where version_id = 289;

This may also be related to #402 but that issue appeared to be more concerned about down behaviour.

We are using goose version v3.7.0 although I note that the (much revised) v3.11.2 also exhibits identical behaviour.

[mfridman]

Thanks for the report. To clarify this point:

My expectation was that if I ran up again, it would report no migrations to be applied because the sequence 284 -> 288 was now complete.

Did you run goose up without the -allow-missing flag on the second run?

[mfridman]

Fwiw that does appear to be the case, and re-reading the Issue title "up following an up -allow-missing" it makes sense.

[mfridman]

Alright, added a failing test to capture this behaviour in 951b141 and the fix should be #524

[jonseymour]

Thank you!