Is your proposal related to a problem?

I recently switched over to using the hasura/graphql-engine:v2.0.9.cli-migrations-v3 image and explicit migrations/metadata tracking for the config-as-code and reproducibility benefits when working across dev/prod/staging, etc.

Everything was working great, and I was able to make schema changes in the web console and have those recorded automatically in my migrations/ directory by virtue of using the console through hasura console instead of HASURA_GRAPHQL_ENABLE_CONSOLE=true.

Fast forward to an accidental configuration change earlier this week: inadvertently, I now had HASURA_GRAPHQL_ENABLE_CONSOLE=true and accessed the console directly instead of via hasura console. As a result, all schema changes since then have not been persisted. So now I have significant drift between what's recorded in migrations/ and the actual hasura schema.

This is a huge footgun.

See https://hasura.io/docs/latest/graphql/core/migrations/migrations-setup.html#step-0-disable-the-console-on-the-server for more info.

Describe the solution you'd like

Either,

1. Using *.cli-migrations images implies HASURA_GRAPHQL_ENABLE_CONSOLE: "false"
2. Allow the web console, but disallow the user from making any schema changes in that mode. Instead provide an error message directing them to run via hasura console.

Describe alternatives you've considered

n/a

If the feature is approved, would you be willing to submit a PR?

Sure, if someone can point me to where the changes would be required.