Handle illegal JSON casting in hdb_catalog.insert_event_log (close #8498)

[trivedi]

Description

Changelog

Component : server

Type: bugfix

Product: community-edition

Short Changelog

Long Changelog

If a Hasura Event Trigger is attached to a table, changes to that table will call the hdb_catalog.insert_event_log function to insert the row’s payload into the hdb_catalog.event_logs table.

This function enriches the payload with information about the user via current_setting('hasura.user', 't'). It then builds a JSON object with this value—along with the changed row, operation, tracecontext, etc)—and attempts to insert this for the hdb_catalog.event_logs.payload JSON column. This creates an implicit casting to JSON.

This assumes that current_setting('hasura.user', 't') will always return JSON or NULL. This is not a safe assumption.
Consider the following:

1. Client app opens a transaction, runs set_config(hasura.user, 'something', 't'), commits
2. Client app updates a table (with an event trigger) directly via SQL
3. hdb_catalog.insert_event_log() is called
4. That function does something to the effect of inserting current_setting('hasura.user', 't') to a json column

This makes Postgres throw an error. The call to current_setting('hasura.user', 't') will return an empty string instead of NULL because of the modification made in the transaction[1].

There are legitimate reasons why someone may set hasura.user via set_config -- the biggest one is so that it can be grabbed for the audit table as described in Hasura's documentation. Queries that go though Hasura will have this information attached. But queries made directly to the database will not. In the latter case, we may still want the information available to the audit log function. And therefore need set the hasura.user manually.

[1] The effect of set_config is accepted behavior in Postgres and the recommendation is that it should be handled by callers.

Related Issues

#8498

Solution and Design

• Updates the function to fallback to NULL if it encounters an empty string for the configuration parameters.
• This is also consistent with the function’s behavior for old versions of Postgres. At the moment this actually means there's inconsistency in behavior.

Steps to test and verify

1. Create an event trigger on some table
2. Manually update hasura.user in a transaction

• BEGIN; set_config('hasura.user', {}); COMMIT;

6. Update the table that has the event trigger in some way via directly querying the database
7. See that an error is not thrown

Limitations, known bugs & workarounds

Server checklist

Catalog upgrade

Does this PR change Hasura Catalog version?

• No
• Yes
  • Updated docs with SQL for downgrading the catalog

Metadata

Does this PR add a new Metadata feature?

• No
• Yes
  • Does run_sql auto manages the new metadata through schema diffing?
    • Yes
    • Not required
  • Does run_sql auto manages the definitions of metadata on renaming?
    • Yes
    • Not required
  • Does export_metadata/replace_metadata supports the new metadata added?
    • Yes
    • Not required

GraphQL

• No new GraphQL schema is generated
• New GraphQL schema is being generated:
  • New types and typenames are correlated

Breaking changes

• No Breaking changes

• There are breaking changes:

  1. Metadata API

     Existing query types:

     • Modify args payload which is not backward compatible
     • Behavioural change of the API
     • Change in response JSON schema
     • Change in error code

  2. GraphQL API

     Schema Generation:

     • Change in any NamedType
     • Change in table field names

     Schema Resolve:-

     • Change in treatment of null value for any input fields

  3. Logging

     • Log JSON schema has changed
     • Log type names have changed