When using multi-stage migrations, a failure in stage 2 leaves stage 1 committed, even with a proper down statement

[fooshards]

Based on the documentation of this projects README.md on stage migrations.... Given the migrationfile:

-- description: Example multistage
-- authoredAt: 1474034307117
-- up:

-- stage: 1
CREATE TYPE foo (
  username text,
  comments text
);

-- stage: 2
CREATE TYPE bar (
  line_one text,
  line_two text
);

-- stage: 3
CREATE TYPE invalid (
  herp derp,
  omg syntax
);

-- down:

-- stage: 1
DROP TYPE invalid
;

-- stage: 2
DROP TYPE bar
;

-- stage: 3
DROP TYPE foo
;

When run, it will error on the obvious syntax bomb in stage 3, and not write a line into the applied_migrations table (meaning this file will re-execute next run)

However, this leaves behind types foo and bar. So next run, you get a different cql error: "type foo already exists"

It feels like the tool should attempt to run stage downs if stage ups failed. This can be seen as trying to bring it back into a state where the whole thing can be run again.

This behavior forces you to use "IF NOT EXIST" on pretty much all statements to mitigate, which is an effective workaround, but could be undesirable in practice.