Does Cypress cy.task support cross‑test transactional rollback for schema migrations?

Answer

Short answer: No. A cy.task runs in a short‑lived Node.js process that exits when the task finishes. Any database transaction started inside that task is closed before the next task or test runs, so Cypress cannot automatically roll back a schema change across multiple tests.

Why this is the case

• Each cy.task spawns a fresh Node process. The process ends immediately after the task resolves.
• Database drivers keep a connection open only for the lifetime of the process. When the process exits, the driver closes the connection, which automatically commits or rolls back any open transaction.
• Migration libraries such as Knex or Sequelize expose transactions only within a single connection context; they cannot be handed off to another process or test.
• Cypress provides no built‑in mechanism to share a connection or keep a transaction alive across test boundaries.

Practical patterns to achieve isolation

1. Wrap migration and rollback in one task:

   cy.task('runMigration').then(() => {
     // test code
   });
   // In the task implementation:
   //   start transaction
   //   run migration
   //   if test fails, rollback
   //   else commit
   

2. Reset the database in beforeEach or afterEach:

   beforeEach(() => {
     cy.task('resetDatabase');
   });
   

   This ensures every test starts with a clean schema.
3. Use a dedicated test database that is dropped and recreated for each test run, rather than relying on transactional rollback.

When you might still need a transaction

If you only need transactional isolation for data changes (not schema changes), you can start a transaction in a task and commit/rollback within the same task. For schema changes, the above patterns are the reliable approach.

Ask for missing detail (if needed)

If you are using a database that supports nested transactions or savepoints, let us know, as that can influence how you structure your reset logic.