Confirm your tables use a transactional engine before relying on rollback
An import wraps its writes in a transaction, throws an exception, and still leaves changes behind. Before blaming the framework, verify that the tables involved use an engine with the transaction behavior you expect.
Inspect the table definition
SHOW TABLE STATUS LIKE 'invoices';
SHOW CREATE TABLE invoices;
Check the engine and constraints in the real environment. InnoDB supports transactions and row-level locking, while other engines have different behavior. An old imported schema may not match new tables created by current migrations.
One operation can touch several systems
Even when all database tables are transactional, filesystem writes, emails, and remote API calls do not roll back with MySQL. Inventory the entire operation before describing it as atomic.
Some SQL statements cause implicit commits. Schema changes should not be treated like ordinary row updates that can always be rolled back inside an application transaction. Review migration behavior separately from business transactions.
Test a deliberate exception after the first write and verify every intended database change is rolled back. Run the test against the same engine family used in production. A passing SQLite test does not establish MySQL engine configuration.
If a table needs conversion, plan and back up that change carefully with representative data. Do not casually alter a large live table during a request-level bug investigation. First establish the cause, data size, constraints, and recovery path.