When specifying a different metadata db, event triggers are recreated

[gratus-acuitymd]

Version Information

Server Version: v2.20.1 CLI Version (for CLI related issue):

Environment

CE, running locally on Docker

What is the current behaviour?

I am providing Hasura with a metadata db URL and a graphql db URL. Hasura seems to read correctly from the metadata db - remote schemas etc. are all visible over the console and I get the green checkbox.

However, it wants to write to the hdb schema on the graphql db - for example changes to permissions, event logs etc.

What is the expected behaviour?

The console should respect the metadata url and write to the same metadata db that it is reading from.

How to reproduce the issue?

1. Set up ur metadata using the migrations image
2. Start the hasura grapqhl server and provide a metadata db url and graphql db url
3. Ensure that the username used for the graphql db does not have write permissions on the hdb schema of the graphql db ( otherwise it will just silently write to that db without errors). Ensure that the username used for the metadata db has permission to write to the hdb schema of the metadata db.
4. Do something over the console that changes the metadata (like updating permissions)
5. Notice the logs complaining that it does not have permission to write to the hdb schema.

Screenshots or Screencast

Please provide any traces or logs that could help here.

Any possible solutions/workarounds you're aware of?

We keep our metadata as yaml. I can modify the metadata yaml files and start the migrations image - it will update the correct metadata db and loading the graphql engine subsequently will reflect the metadata changes.

Keywords

metadata, hasura console

[abooij]

I'm not 100% sure yet what is going on here (I'd have to dive a bit deeper), but let me at least call out the following. If Event Triggers are configured for a table in a source DB (i.e. for one of the entries in your databases.yaml) then Hasura builds and maintains a certain amount of state in that DB. Most of it is in the hdb_catalog schema - indeed the same schema name as what's in the Metadata DB - and some of it is in the form of Postgres triggers which are applied to the relevant user tables (i.e. outside of hdb_catalog). Hasura requires write permissions to maintain both elements of this state.

IOW: If the project uses Event Triggers, then Hasura writes to your DB even if the Metadata is stored elsewhere.

[rccoe]

The issue here isn't that hasura doesn't have write access to either database, its that it should only have write access to hdb_catalog on the database that has been defined as the HASURA_GRAPHQL_METADATA_DATABASE_URL.

When saving changes to metadata in hasura console, it attempts to write to hdb_catalog on the HASURA_GRAPHQL_DATABASE_URL, which is clearly wrong given that it's definitely reading from HASURA_GRAPHQL_METADATA_DATABASE_URL

[tirumaraiselvan]

If you have Event Triggers in your metadata, then Hasura writes to your source DB because ET store events in the source DB (and not in metadata DB).

Postgres requirements for DB is mentioned here: https://hasura.io/docs/latest/deployment/postgres-requirements/#user-database

[gratus-acuitymd]

Thanks - quick question to validate something we saw. Does Hasura apply all metadata on each metadata change? I noticed that when I changed permissions on a table, it also attempted to recreate all the event triggeers.

[tirumaraiselvan]

Fixed in https://github.com/hasura/graphql-engine/commit/79836af054e884e44215cf1bb14af2d2b612a135

This should be out in next release

[tirumaraiselvan]

We needed to revert https://github.com/hasura/graphql-engine/commit/79836af054e884e44215cf1bb14af2d2b612a135 because it doesn't account for a complicated edge case.

[lukaszraczylo]

Any update on this one?