Pass the original request context to `onReject` handlers

[Betree]

We are looking to adapt the rejection strategy based on who's calling our API. If it's a trusted account, we'll just log the complexity warning and move on. If it's not, we'll reject the request.

Proposed Solution
A possible way to handle that would be to have the original GraphQLRequestContext object available in the handler call. Pass the GraphQLRequestContext object via the first argument, context, so that it can be accessed as context.graphqlRequest. This would allow handlers to make informed decisions based on request metadata.

Example Usage

onReject: (context, error) => {
  const originalReq = context.graphqlRequest.contextValue;
  if (isTrustedAccount(originalReq.remoteUser)) {
    logWarning(requestContext);
  } else {
    throw new Error("Request rejected due to complexity constraints");
  }
}

Would love to hear your thoughts on this. I'm also open to contributing if we can reach a consensus on the specs.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[Lainocs]

Hey! Thanks a lot for opening this and sharing the idea.

I might be misunderstanding, but I’m not entirely sure I follow the motivation. It seems like you're trying to access the GraphQLRequestContext inside the onReject handler — but since that runs very early in the request lifecycle, the context might not be fully available at that point.

If you could share a bit more context around your use case or what you’re aiming to achieve, that’d be super helpful! Just want to make sure we’re on the same page before digging deeper.

Thanks again 🙌

[Betree]

Hi @Lainocs!

We basically want to adapt our rejection strategy based on some criteria like:

• Is the request coming from an authenticated user?
• Is the request coming from our own tools or from someone else calling the API?

Depending on these checks, we may want to either adapt the max cost allowed (e.g., you can do 100_000 if you're authenticated, 50_000 otherwise) or even completely bypass it.

The information we need is available in the request object (e.g. req.remoteUser), which is why I suggested exposing it in onReject, but other patterns could work for us as well.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[Betree]

We'd still like to have this.