Skip to content

HttpRequestInvokerImpl swallows Exception that prevents sending the error description to client e.g., for timeout error #298

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

Closed
msingh-ms opened this issue Feb 10, 2021 · 5 comments · Fixed by #342
Labels
Milestone

Comments

@msingh-ms
Copy link

msingh-ms commented Feb 10, 2021

Describe the bug
HttpRequestInvokerImpl swallows Exception that prevents sending the error description to client e.g., for timeout error

try {
GraphQLQueryResult result = invoke(invocationInput, request, response).join();
writeResultResponse(invocationInput, result, request, response);
} catch (Exception t) {
writeErrorResponse(t, response);
}

To Reproduce
Steps to reproduce the behavior:

Define a Timeout Instrumentation as follows:

private static class MaxQueryTimeInstrumentation extends SimpleInstrumentation
{
    // Time limit in milliseconds
    private long maxQueryTime = 5000;

    public MaxQueryTimeInstrumentation(long maxQueryTime)
    {
        this.maxQueryTime = maxQueryTime;
    }

    private static class TimerInstrumentationState implements InstrumentationState
    {
        private Instant start = Instant.now();

        private boolean test(long maxQueryTime)
        {
            return ChronoUnit.MILLIS.between(start, Instant.now()) > maxQueryTime;
        }
    }

    @Override
    public InstrumentationState createState()
    {
        return new MaxQueryTimeInstrumentation.TimerInstrumentationState();
    }

    @Override
    public InstrumentationContext<Object> beginFieldFetch(InstrumentationFieldFetchParameters parameters)
    {
        if (((MaxQueryTimeInstrumentation.TimerInstrumentationState) parameters.getInstrumentationState())
                .test(maxQueryTime))
            throw new GraphQLException("allocated time limit exceeded");

        return super.beginFieldFetch(parameters);
    }
}

Run a query that times out.

Expected behavior
If request times out then there will be Exception based on timeout and we should be able to let client know that request timed out.

Screenshots
image

@msingh-ms msingh-ms added the bug label Feb 10, 2021
@oliemansm
Copy link
Member

oliemansm commented Feb 21, 2021

@msingh00021 Could you throw an AbortExecutionException instead of this generic GraphQLException and try again? That exception is also used for other security related instrumentations, such as max query depth, and is caught and converted into an error response.

@msingh-ms
Copy link
Author

@oliemansm AbortExecutionException only works when the data fetching process has not started. If, lets say 25% of data is retrieved and request times out then there will be 200 OK response with only data section without any error section in payload

@oliemansm
Copy link
Member

Converting exceptions thrown from the graphql-java ecosystem into proper GraphQL responses is the responsibility of the graphql-java library. I've done some digging around, and it seems that handling exceptions thrown from instrumentations has been a known issue for a long time already (2017), see graphql-java/graphql-java#460.

I've looked into several ways using the current version (16.2) to see if there's a way to recognize that exception being thrown and manipulate the ExecutionResult. For example by looking into the InstrumentationContext.onCompleted callback. The ExecutionResult interface does not provide any means to add any errors to it if it doesn't contain any errors already unfortunately.

@oliemansm
Copy link
Member

@msingh00021 I've implemented something for this after all. Will be part of 11.1.1. Error response will be a status OK and body in line with the exception that was thrown:

{
  "errors": [
    {
      "message": "allocated time limit exceeded",
      "locations": []
    }
  ],
  "data": null
}

@oliemansm oliemansm linked a pull request May 13, 2021 that will close this issue
@oliemansm oliemansm added this to the 11.1.1 milestone May 13, 2021
@msingh-ms
Copy link
Author

msingh-ms commented May 13, 2021

@oliemansm, Thank you so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants