medusa

Highlights

Fix Migrations Regressions

Following the MikroORM update in v2.13.6, a regression was introduced where running medusa db:migrate generated a full database snapshot for custom modules. Then, when running medusa db:generate later, a bug in the migration generation caused the module snapshot to be overridden by the database snapshot, which would then generate migrations dropping all the tables in the database.

We encourage all users on a version after v2.13.6 to update to this release to mitigate database issues.

After updating, please inspect the migrations/.snapshot.**.json files in your custom modules and:

• Delete any snapshots with the name .snapshot-<db-name>.json.
• For module snapshots (.snapshot-<module-name>.json), confirm that they don't include table names outside of your module, such as product, order, etc... if so, delete those snapshots and regenerate again with medusa db:generate.

You can also use the following prompt with your AI agent:

# Cleaning Up Incorrect Snapshot Files

A bug in earlier versions of Medusa caused `db:migrate` to generate snapshot files named after the database (e.g. `.snapshot-medusa.json`) instead of the module. In some cases, running `db:generate` afterward would overwrite the correct module snapshot with this full-database snapshot, causing the next generated migration to contain `DROP TABLE` statements for all Medusa core tables.

Follow the steps below after updating to v2.15.2 that includes this fix.

## Step 1: Delete database-name snapshots

Look in each module's `migrations/` directory for snapshot files named after your database rather than the module. These are incorrectly generated files and should be deleted.

They look like:

```
.snapshot-medusa.json
.snapshot-my-store.json
.snapshot-medusa-medusa-resolutions.json
```

The correct snapshot is named after the module:

```
.snapshot-<module-name>.json
```

Delete any file that does not follow the module-name pattern.

## Step 2: Check for corrupted module snapshots

Open the remaining `.snapshot-<module>.json` file for each module and check its `tables` array. It should only contain tables owned by that module.

If it contains tables from other modules (e.g. `order`, `cart`, `product`, `customer` inside a small custom module), the snapshot was overwritten by the full-database snapshot and is corrupted.

## Step 3: Regenerate corrupted snapshots

For each corrupted snapshot:

1. Delete the corrupted snapshot file.
2. Regenerate it by running:

```bash
npx medusa db:generate <moduleName>
```

## Step 4: Review the regenerated migration

Open the newly created migration file and check its contents. If it contains `DROP TABLE` or unexpected `ALTER TABLE` statements for tables that belong to other modules:

1. **Do not run this migration.**
2. Delete the migration file.
3. The snapshot has now been regenerated correctly — subsequent runs of `db:generate` will produce accurate migrations.

Features

• feat(medusa): enable index when querying products via promotion attribute values and enable sku search in products entrypoint by @NicolasGorga in #15386

Bugs

• fix(utils): disable generating snapshots on running migrations by @shahednasser in #15382
• fix: build should throw if medusa-config throws by @peterlgh7 in #15383
• fix(locking-redis): add jitter to Redis lock retry backoff by @Suh0161 in #15274

Chores

• chore(docs): Generated References (automated) by @app/github-actions in #15376
• chore(docs): Updated UI Reference (automated) by @app/github-actions in #15374
• chore(docs): Update version in documentation (automated) by @app/github-actions in #15373

Full Changelog: v2.15.1...v2.15.2