Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error 400 when working with rover graph introspect #1445

Closed
tsibelman opened this issue Dec 4, 2022 · 2 comments
Closed

Error 400 when working with rover graph introspect #1445

tsibelman opened this issue Dec 4, 2022 · 2 comments
Labels
bug 🐞 triage issues and PRs that need to be triaged

Comments

@tsibelman
Copy link

Description

Created an Apollo express server, was able successfully go to http://localhost:4000 in the browser and expect the schema.
Tried to run "rover graph introspect http://localhost:4000" get back 400 error. If I run rover with debug logger, I see an error like this:

  DEBUG introspector_gadget::blocking::client: {"errors":[{"message":"`variables` in a POST body must be an object if provided.","extensions":{"code":"BAD_REQUEST","stacktrace":["BadRequestError: `variables` in a POST body must be an object if provided.","    at new GraphQLErrorWithCode (/Users/michaeltsibelman/repos/docontrol/adam/node_modules/@apollo/server/src/internalErrorClasses.ts:15:5)","    at new BadRequestError (/Users/michaeltsibelman/repos/docontrol/adam/node_modules/@apollo/server/src/internalErrorClasses.ts:116:5)","    at runHttpQuery (/Users/michaeltsibelman/repos/docontrol/adam/node_modules/@apollo/server/src/runHttpQuery.ts:169:15)","    at runPotentiallyBatchedHttpQuery (/Users/michaeltsibelman/repos/docontrol/adam/node_modules/@apollo/server/src/httpBatching.ts:85:30)","    at ApolloServer.executeHTTPGraphQLRequest (/Users/michaeltsibelman/repos/docontrol/adam/node_modules/@apollo/server/src/ApolloServer.ts:1038:50)","    at processTicksAndRejections (node:internal/process/task_queues:96:5)"]}}]}

    at /Users/distiller/.cargo/registry/src/github.com-1ecc6299db9ec823/introspector-gadget-0.2.0/src/blocking/client.rs:133

Steps to reproduce

A minimal repro app

import { expressMiddleware } from '@apollo/server/express4';
import { ApolloServer } from '@apollo/server';
import { buildSubgraphSchema } from '@apollo/subgraph';
import express from 'express';
import http from 'http';
import cors from 'cors';
import { json } from 'body-parser';
import gql from 'graphql-tag';

export const typeDefs = gql`
    """
    Adam entry
    """
    type AdamEntry {
        """
        Name field
        """
        name: String!

        """
        Job field
        """
        job: String!
    }

    """
    Query
    """
    type Query {
        """
        Get entity by status
        """
        get: AdamEntry!
    }
`;

export interface IEntity {
    name: string;
    job: string;    
}

const schema = buildSubgraphSchema({
    typeDefs,
    resolvers: {
        Query: {
            async get(): Promise<IEntity> {                
                return {name:"test", job:"test"};
            },
        }
    }    
});

export const apolloServer = new ApolloServer({
    schema,
    introspection: true,
});

await apolloServer.start();

const app = express();
const httpServer = http.createServer(app);

app.use(
    '/graphql',
    cors<cors.CorsRequest>(),
    json(),
    expressMiddleware(apolloServer),
);

await httpServer.listen({ port: 4000 })
console.log(`🚀 Server ready at http://localhost:4000/graphql`);

Environment

Rover Info:
Version: 0.10.0
Install Location: /Users/michaeltsibelman/repos/docontrol/adam/node_modules/binary-install/node_modules/.bin/rover
OS: Mac OS 13.0.1 [64-bit]
Shell: /bin/zsh

@tsibelman tsibelman added bug 🐞 triage issues and PRs that need to be triaged labels Dec 4, 2022
@tsibelman
Copy link
Author

tsibelman commented Dec 6, 2022

I debuged it further looks like you send request with JSON like this
{
"variables": null,
"query": "query GraphIntrospectQuery { __schema { queryType { name } mutationType { name } subscriptionType { name } types { ...FullType } directives { name description locations args { ...InputValue } } }}fragment FullType on __Type { kind name description fields(includeDeprecated: true) { name description args { ...InputValue } type { ...TypeRef } isDeprecated deprecationReason } inputFields { ...InputValue } interfaces { ...TypeRef } enumValues(includeDeprecated: true) { name description isDeprecated deprecationReason } possibleTypes { ...TypeRef }}fragment InputValue on __InputValue { name description type { ...TypeRef } defaultValue}fragment TypeRef on __Type { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } }}",
"operationName": "GraphIntrospectQuery"
}

But apollo server v4 is not expecting to get this as a null
https://github.com/apollographql/apollo-server/blob/18501ffeeffe1a7751e841c8c365ba8b277d73ac/packages/server/src/runHttpQuery.ts#L172

Looks like this change was introduced 15 days ago apollographql/apollo-server@37b3b7f and this a regression between rover and server

tsibelman referenced this issue in apollographql/apollo-server Dec 6, 2022
This PR adds the spec audit suite from `graphql-http` (designed to
validate compatibility with the "GraphQL over HTTP" specification) to
the integration test suite. It expects all required (MUST) audits to
pass, and for all optional (MAY/SHOULD) audits to pass that we haven't
explicitly excepted.

All required audits already passed. Failing optional audits fell into
three categories:

- Ignoring `operationName`, `variables`, and `extensions` when provided
with incorrect types instead of returning a 400 error. The SHOULD here
seemed reasonable and so this PR changes our POST handler to return 400s
if incorrect types are provided here. As described in the changeset,
this is backwards incompatible but we are comfortable making this choice
today.
- Returning 400 errors for various error conditions like GraphQL parse
errors, for the original `application/json` response type. The one
aspect of the GoH spec that is prescriptive rather than descriptive is
the invention of the `application/graphql-response+json` response MIME
type; the theory is that you can't really "trust" that a non-2xx
response with MIME type `application/json` is actually generated by the
GraphQL server rather than by some other proxy, so it has you use this
new type along with 4xx for these errors, and then SHOULDs that these
errors come with 200 for the original MIME type. The main reason that
this is a SHOULD is because many servers like Apollo Server already
return 400s in this case, and we're not interested in changing that. So
we ignore these particular errors.
- There's a sorta buggy audit that has opinions about how bad JSON
errors should look. See
graphql/graphql-http#25

Note that we deliberately make a strict dependency on a single version
of graphql-http, so that the tests run by a given version of
`@apollo/server-integration-test-suite` are well defined.

Fixes #7158.

Co-authored-by: Denis Badurina <badurinadenis@gmail.com>
@EverlastingBugstopper
Copy link
Contributor

Hi @tsibelman - this was a regression in Apollo Server 4.2.0 and was fixed in this PR. If you update to apollo server 4.2.2 this issue should be resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐞 triage issues and PRs that need to be triaged
Projects
None yet
Development

No branches or pull requests

2 participants