hasura / hasura/graphql-engine

Regression in v2.0: Migration State was Stripped from the Database

Open
#7,610 8 comments 8 reactions 0 assignees View on GitHub
c/cli c/migrations k/bug k/enhancement support/needs-triage
Dominant language
TypeScript
Stars
32.1k
Forks
3k
PR merge metrics
PR metrics pending

Description

### Version Information

Server Version: 2.0.3

### Environment

Cloud

### What is the expected behaviour?

- The version of the database (migration state) is stored inside the database

### Keywords

- Migrations

### What is the current behaviour?

- The version of the database is now saved on Hasura Cloud's servers as confirmed by the awesome team at Hasura support (Rikin and Benoit)
- The table `hdb_catalog.schema_migrations` is still present in the database but it's not being populated anymore since v2
- Locally and on self-hosted instances, the migration state is now stored inside of a JSON at `hdb_catalog.hdb_version.cli_state` but this value is empty on Hasura Cloud instances

### How to reproduce the issue?

1. Start with a local environment and a PROD environment that are on the same database version (all migrations applied)
2. Create a new migration locally, run it against PROD
3. Create a second migration locally, but do not run it on PROD
3. Now dump the PROD DB and restore it locally
4. Run `hasura migrate apply` locally => Error, table/column already exists

### Any possible solutions?

Two solutions:
- Fast & easy: populate `hdb_catalog.hdb_version.cli_state` in databases connected to Hasura Cloud
- Even better: revert to using the `hdb_catalog.schema_migrations` table which was really convenient

Why?
- The version of the database is a crucial piece of information that actually belongs together with the data.
- Being able to restore PROD locally and knowing which migrations to run and which ones to skip is of paramount importance for a smooth development experience.

We are a team of 20 developers, everyone is writing migrations. Sometimes they fail and they must be rewritten. Sometimes they conflict with each other. By dumping a copy of PROD, restoring locally and running only the latest migrations we can enforce consistency and improve developer's workflow. Also, every time someone does it locally, it serves as a dry run for when we actually deploy the migrations on PROD.

### Can you identify the location in the source code where the problem exists?

No because this is specific to Hasura Cloud.

### If the bug is confirmed, would you be willing to submit a PR?

No because this is specific to Hasura Cloud.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.