Changes not reverted after an exception occurs

When an SQL error or any other exception occurs during the migration, the database remains in an intermediary state and

• can not be migrated as the migration is partially applied (e.g. the tables already exist)
• can not be reverted, because the migration does not appear in the phinxlog log

A simple use case:

    public function change(): void
    {
        $users = $this->table('users')->create();
        throw new Exception();
    }

The users table will be left in the database after the exception is thrown and the migration can neither be reverted nor repeated after the issue is fixed,
because of PDOException: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'users' already exists.

Does this not defy the purpose of a migration toolkit?

The interesting part is that I can see TRANSACTION START if I do dry-run.

START TRANSACTION;
CREATE TABLE `users` (`id` INT(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`)) ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_general_ci;
Exception in ...

version: 0.12.5 + MariaDB

Start with the migration containing change() and reproduce the failure against MariaDB, comparing normal execution with the dry-run transaction output. Trace the transaction handling around the SQL error; done means the users table is not left behind and the migration can be rerun or reverted after the exception.