Migrations with default value of column are not applied correctly

[co6x0]

Version Information

• Server Version: 2.0.10
• CLI Version (for CLI related issue): 2.0.9

Environment

OSS (used in Docker Compose)

• Docker Desktop: 4.1.1 (Docker Engine: 20.10.8)

What is the expected behaviour?

migrate apply command correctly execute SQL commands with default values.

Keywords

column default value, migrate column default, no such column exists

What is the current behaviour?

Running the following SQL command of migration, Hasura Console will display an alert saying Browse query failed! no such column exists : "is_active", and the data in this table will no longer be displayed in Hasura Console.

This example is automatically generated by Hasura Console (provided by hasura console command).

alter table "public"."users" add column "is_active" boolean
 null default 'false';

However, after checking the data in this table using the Raw SQL feature of Hasura Console, I confirmed is_active column existence and each field had f literal value representing false.

Accessing this column once in Hasura Console seems to fix this problem, but I will not be able to request this column in GraphQL until it is fixed.

This is a slightly tricky problem, especially if not enabled Hasura Console in a production environment.

How to reproduce the issue?

1. Run hasura console command
2. Add a new column with default values in launched Hasura Console
3. Duplicate the folder containing the automatically generated SQL for migration and save it somewhere
4. Delete the migration with the migrate delete command
5. Relocate the duplicated folder to the migrations directory
6. Run migrate apply command
7. Check the table to which the new column should be added in Hasura Console

Please provide any traces or logs that could help here.

Message of error notification from Hasura Console

Browse query failed!
no such column exists : "is_active"

Logs of hasura/graphql-engine on Docker

{"type":"http-log","timestamp":"2021-11-04T05:14:07.169+0000","level":"error","detail":{"operation":{"user_vars":{"x-hasura-role":"admin"},"error":{"path":"$[0].columns[3]","error":"no such column exists : \"is_active\"","code":"permission-denied"},"request_id":"b950a215-91d2-400f-b900-52a4a1e2d3d1","response_size":101,"query":{"args":[{"args":{"source":"default","columns":["user_id","created_at","updated_at","is_active"],"limit":100,"table":{"schema":"public","name":"users"}},"type":"select"},{"args":{"cascade":false,"source":"default","sql":"SELECT\n    reltuples::BIGINT\n  FROM\n    pg_class c\n  JOIN\n    pg_namespace n ON c.relnamespace = n.oid\n  WHERE\n    c.relname = quote_ident('users') AND n.nspname = quote_ident('public');","read_only":true},"type":"run_sql"}],"source":"default","type":"bulk"},"request_mode":"error"},"request_id":"b950a215-91d2-400f-b900-52a4a1e2d3d1","http_info":{"status":400,"http_version":"HTTP/1.1","url":"/v2/query","ip":"172.30.0.1","method":"POST","content_encoding":null}}}

Any possible solutions?

Access the column added after the migration on Hasura Console.
For example, add comments to the column, run SQL commands like select is_active from users, etc.

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

No, I can't identify the problem, probably.

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

If the cause exists in the Hasura Console(served by the Hasura CLI), I may be able to submit a PR.

[dminkovsky]

Hi @naokomura. Thanks for reporting this—I am experiencing this, too. I am on v2.0.3.

Can you please clarify what you mean by this?

Accessing this column once in Hasura Console seems to fix this problem

Thank you,
Dmitry

[dminkovsky]

Looks like I am able to solve this issue by any of the following methods:

• Restart Hasura

OR

1. Applying the migration
2. In the console, navigating to /console/settings/metadata-actions by clicking on the gear in the top right corner.
3. Click "Reload" in the "Reload metadata" section, with "Reload all databases" checked, for some reason.

---

hasura migrate apply does not fix the issue.

[cakemountain]

@dminkovsky @naokomura I've also experienced this with Hasura v2.0.10-cloud.1. After applying new migrations/metadata to a production instance from the Hasura CLI I had to "Reload metadata" with "Reload all databases". I'm also unsure why.

[david58]

correct however the poorly documented solution is to run hasura metadata reload

[jflambert]

There's possible overlap between this issue and mine (#8245)

Whereas this issue focuses on hasura migrations not immediately reloading metadata, I request that the inconsistency flag be raised.

But in the end we both just want hasura to support external modifications to the database sources.