Decorated type deeper than introspection query. 4d array

[TheAschr]

It does not seem like this library supports 4d arrays.

I have this type defined on my server

type MultiPolygon {
  type: GeometryType!
  coordinates: [[[[Float!]!]!]!]!
  bbox: [Float!]
}

When I try to load the graphql playground I get this error:

Uncaught Error: Decorated type deeper than introspection query.
    at m (buildClientSchema.mjs:69)
    at m (buildClientSchema.mjs:82)
    at m (buildClientSchema.mjs:72)
    at m (buildClientSchema.mjs:82)
    at m (buildClientSchema.mjs:72)
    at m (buildClientSchema.mjs:82)
    at m (buildClientSchema.mjs:72)
    at m (buildClientSchema.mjs:82)
    at w (buildClientSchema.mjs:251)
    at keyValMap.mjs:20

This error only occurs when I change the coordinates field from 3d to 4d.

I'm wondering if this is a bug that is fixable or is there a workaround?

[danielrearden]

@TheAschr As a workaround, Playground allows you to pass in an introspection result so it won't run the initial query itself. You could modify the "official" introspection query and increase the depth of the TypeRef fragment

fragment TypeRef on __Type {
      kind
      name
      ofType {
        kind
        name
        ofType {
          kind
          name
          # and so on...

Run this query against your schema and then pass the data returned to Playground as the schema property. If you're using Apollo, so you can pass this in as part of your configuration:

const server = new ApolloServer({
  schema,
  playground: {
    schema: introspectionResult
  }
});

Here's a complete example. You'll still see the error in the console if Playground attempts to fetch the introspection query again, which it does periodically by default. But at least this way, you'll have autocomplete and working schema and docs tabs.

[danielrearden]

I think it might be worthwhile to add some kind of ofTypeDepth property to IntrospectionOptions, which could then also be exposed by tools like GraphiQL/GraphQL Playground.

[hally9k]

Just bumped into this due to geojson multipolygons having 4d arrays for coordinates. I like the config suggestion by @danielrearden above. Also I feel like the default should be changed to support 4d arrays as geojson is becoming ubiquitous in a lot of geospatial applications so more and more people will continue to bump into this limitation.

[gf3]

we also use a similar type for the same reason (MongoDB geospatial queries), i think 4d arrays are probably a saner default here

"""
Location zone of operation.
"""
type Geometry {
  coordinates: [[[[Float!]!]!]!]!
  type: String!
}

[abouroubi]

I'm here for the exact same reason, using GeoJSON MultiPolygon, has anything been done to solve this ?

[gf3]

i attempted to fix this however i couldn't find where in the code the limit is. it seems to parse the array just fine, but it's something specific to introspection queries

[gf3]

ping @IvanGoncharov: this issue affects anyone using GeoJSON which is built into many databases including MongoDB. seems like a relatively straightforward fix for someone familiar with the codebase

[dylandong12]

we are also using GeoJSON MultiPolygon. not supporting 4d arrays blocks us from using graphql type generation tooling as well. @IvanGoncharov any idea to fix this, please?

[drbarber]

This is an error that has been plaguing me as well and I ended up resolving the issue by implementing a custom scalar as a workaround. Maybe not a perfect solution but it seems to be working well.

export const CoordinateScalar = new GraphQLScalarType({ name: 'coordinates', serialize(value) { return value; }, parseValue(value) { return value; }, });

[gschulze]

Any update on this issue? I'm running into the same problem implementing GeoJSON input/output of MultiPolygons. Is there a timeline when this will be fixed? I'd be willing to contribute if desired.

[abouroubi]

@gschulze the issue was opened 3 years ago, I think they don't care.