Tests fail upon a fresh install about auth HOT 6 CLOSED

I think the short term fix is to pin the dependency. Would that work @jonnydgreen?

Yeah that also works! I'll get something out later today

I tend to avoid using graphql-tools for these kind of reasons. So possibly could we just remove the dependency? Fixing upstream is also ok.

Yeah that also works and if we remove it, gives us more confidence long-term - I'll take a look at both and work out what would be best!

from auth.

Looks like the issue is with a downstream dependency of @graphql-tools/wrap because if I set these explicitly to the versions when @graphql-tools/wrap was installed, it works:

{
  ...
  "dependencies": {
    "@graphql-tools/wrap": "8.3.2",
    "@graphql-tools/delegate": "8.4.2",
    "@graphql-tools/schema": "8.3.1",
    "@graphql-tools/utils": "8.5.3",
    "fastify-error": "^1.0.0",
    "fastify-plugin": "^3.0.0",
    "graphql": "^16.2.0"
  },
  ...
}

Still investigating

from auth.

Have scheduled some time tomorrow to figure out the solution for the sudden CI failures as this is a big blocker

from auth.

Found the problem dependency: https://www.npmjs.com/package/@graphql-tools/utils

The patch upgrade from 8.6.7 => 8.6.x breaks the tests for the introspection schema auth:

Looking at the source code this for dependency to find out what has changed

from auth.

Update: have figured out the issue - the @graphql-tools/[email protected] is now pruning empty root types which is causing the introspection queries to fail in the GraphQL executor.

Consider the following schema:

directive @hideMe on OBJECT

type Message @hideMe {
  message: String
  password: String
}

type Query {
  publicMessages(org: String): [Message!]
}

When a user does not have access to the Message type, and runs an introspection query, the PruneSchema transformer removes the publicMessages field from the Query type. Previously, it used to stop there, but now it also removes the (now empty) Root Query Type from the schema as well. We have code to account for this, but it looks like it is no longer being adhered to as the root types are still being pruned. It looks like this was introduced in this PR: ardatan/graphql-tools#4380

new PruneSchema({
  skipPruning (type) {
    // skip pruning if the type is the Query or Mutation object
    return type instanceof GraphQLObjectType && (type.name === 'Query' || type.name === 'Mutation')
  }
})

What's the issue with this? The issue is that introspection queries now fail because when GraphQL executes, it tries to find the root type and fails if it does not exist. Therefore, instead of a response of:

{
  data: {
    __type: null
  }
}

We now get the Schema is not configured to execute query operation error where the skipPruning function in the transformer is no longer adhered to.

Proposed solution

I think there are potentially staged approaches here, short, and long-term:

Short-term

This solution is not ideal so if we are all happy to wait for a downstream fix, we could skip this.

Re-add the empty root types (if they don't exist) to the pruned schema in our codebase (with a TODO to remove) and add a specific test to account for this edge-case - I could get a fix out for this ASAP. I would recommend backporting the fix to all major versions as well.

Long-term

Resolve the issue in the downstream dependency and remove the code that re-adds the root types if it exists. Add a specific test in mercurius-auth if it does not yet exist.

What do you think @mcollina @Eomm ?

• Long and short term?
• Long term only?
• Explicitly handle error
• Something else

from auth.

I think the short term fix is to pin the dependency. Would that work @jonnydgreen?

I tend to avoid using graphql-tools for these kind of reasons. So possibly could we just remove the dependency? Fixing upstream is also ok.

from auth.