cli: fix bug when exporting metadata to remote_schemas.yaml

[kmtym1998]

Description

• Use FormatSchemaDocument to format remote schema permission instead of FormatSchema because FormatSchema drops schema {} clause
  • related issue
• This change may affect users when exporting metadata to remote_schemas.yaml

FYI : formatter library code useing on hasura-cli: https://github.com/vektah/gqlparser/blob/v2.4.3/formatter/formatter.go

Changelog

Component : cli

Type: bugfix

Product: community-edition

Short Changelog

fix bug when exporting metadata to remote_schemas.yaml (#8579)

Long Changelog

Related Issues

#8579

Solution and Design

When I click the save permissions button on hasura console, schema string containing schema clause is sent to the endpoint /apis/migrate, so I have determined that it is not a bug in console, but in cli that exports metadata.

I found cli format GraphQL schema using vektah/gqlparser/v2/formatter before exporting metadata to remote_schemas.yaml.

vektah/gqlparser/v2/formatter has two methods to format gql schema (FormatSchema, FormatSchemaDocument). FormatSchema misses schema clause if schema.query is Query. I confirmed the same behavior in case of Mutation and Subscription (related issue). Since this does not happen with FormatSchemaDocument, I decided to use the method.
Differences in two methods behavior can be seen on my fork. Code is here.

Steps to test and verify

1. Connect remote schema
2. Edit and save permissions for a role on hasura console
3. Open remote_schemas.yaml and check if schema {} clause exists on the role
4. Call query / mutation with the role

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

[hasura-bot]

Beep boop! 🤖

Hey @kmtym1998, thanks for your PR!

One of my human friends will review this PR and get back to you as soon as possible.

Stay awesome! 😎

[m-Bilal]

Hi @kmtym1998, thanks for your PR! Sorry for not reviewing this last week, I was a bit busy. I'll take a look at this sometime this week.

[CLAassistant]

All committers have signed the CLA.

[m-Bilal]

@kmtym1998 thank you for taking the time to submit this PR! ❤️ It looks good to me!

@scriptonist I have gone through the changes, can you please glance through this as well and then we can merge this.

[scriptonist]

LGTM @m-Bilal

[hasura-bot]

Beep boop! 🤖

Awesome work @kmtym1998!

Your changes were merged successfully. All of us at Hasura ❤️ what you did.

Thanks again 🤗