GraphQL errors when querying/mutating models in a non-default module

[tomnz]

I am experiencing multiple issues while attempting to use the GraphQL query/mutation endpoints whenever a model is part of a non-default module. See inline below for specific issues and how to trigger them.

• EdgeDB Version: 3.2+740bb0d
• EdgeDB CLI Version: EdgeDB CLI 3.4.0+15c5e18
• OS Version: Docker image @ :latest

Schema

(Untested, but this should reproduce the issues):

using extension graphql;
module default {
  type Parent {
    required single link data: Data {
      constraint exclusive;
      default := (
        insert Data {}
      }
    }

    multi link children := .<parent[is child::Child];
  }
  # Included to demonstrate that errors are not related to nested fields
  type Data {
    link parent := .<data[is Parent];
    value: str;
  }
}
module child {
  type Child {
    required single link parent: default::Parent;
    data: str;
  }
}

Steps to Reproduce

A) Invalid __typename for module-scoped model in query

query {
  Parent(first: 1) {
    __typename
    id
    data {
      __typename
      id
      value
    }
    children {
      __typename
      id
      data
    }
  }
}

The response may look something like:

Parent: [
  {
    __typename: "Parent_Type",
    id: "...",
    data: {
      __typename: "Data_Type",  # This is correct - so the issue is not nested fields
      value: "..."
    },
    children: [
      {
        __typename: "\u0001__\u0002_Type",  # This is invalid!
        id: "...",
        data: "..."
      }
    ]
  }
]

The __typename field for child::Child does not resolve correctly, and will return \u0001__\u0002_Type for any type inside a non-default module. I would expect it to instead return child__Child_Type.

This causes issues for regular GraphQL clients, as they rely on the typename to figure out the concrete type returned for the respective interfaces that the query defines as the return type (e.g. Parent -> Parent_Type).

Note that the __typename works as expected for models in default.

B) Unsupported inline fragment spread for module-scoped model in query

query {
  child__Child {
    ... on child__Child {
      id
      data
    }
  }
}

This is a bit more of an edge case, but we use schema stitching to delegate parts of queries to the EdgeDB graph, and it likes to insert these inline fragment spreads for specific types from the given graph. This syntax results in a flat-out error from EdgeDB: AssertionError: unresolved type std::child__Child

This syntax works fine for models in the default module.

C) Mutation fails if __typename is requested for a module-scoped selection

mutation {
  insert_child__Child(data: [{data: "foo"}]) {
    __typename
    id
  }
}

Simply the presence of __typename in the selection set (which is added automatically by tooling in order to glean the concrete type for an interface) causes an error from EdgeDB: AttributeError: 'NoneType' object has no attribute 'dummy'

Again, this works fine, and the correct type (e.g. Parent_Type) is returned for a mutation on a model in default. Data is also returned without an error if removing __typename from the selection set.

Workaround

As a workaround, for now, I have just lifted everything into the default module - but this is a disappointing solution, and hopefully, there are actual bugs here that can be tracked down! It's worth noting that all of these issues disappear when the models are all in default.

Thanks for taking a look - we love EdgeDB, and the dev team is awesome! If you are unable to repro, let me know, and I can try to figure out the specific combination of properties that triggered this behavior for me.

[vpetrovykh]

The fixes are in #6035
They should be available in the 4.0 release.