Intercepting Apollo graphql validation error via RHAI scripta

I have recently created a self hosted apollo router service in an eks pod, now everything seems to be working fine, the req and res are coming properly as expected. But the apollo router is sending very generic error message in case of graphql validation error. Now I want to intercept the validation error and capture the error via RHAI scripts.

      fn router_service(service) {
        service.map_request(|request| {
          // Log full request event from Gloo Gateway
          log_info(`[ROUTER_EVENT] method=${request.method} uri=${request.uri} headers=${request.headers}`);
        });
      }
      
      fn subgraph_service(service, subgraph) {
        service.map_request(|request| {
          // Log full subgraph request event
          log_info(`[SUBGRAPH_EVENT] subgraph=${subgraph} query=${request.subgraph.body.query} headers=${request.subgraph.headers}`);
        });
      }

I am able to get the logs for successful graphql requests but in case of validation errors I am not able to intercept the logs. Is there a better ref of RHAI scripts available so that I can override some rust function to get the error in RHAI

Hi Ravi,

This is expected behavior with Apollo Router. GraphQL validation errors occur before the request reaches subgraph_service, so RHAI hooks like map_request won’t fire for those cases. Validation happens at the router level, and the response is generated early in the pipeline.

To intercept validation errors, you’ll want to:

  • Use map_response at the router_service level

  • Inspect the GraphQL error extensions (e.g. extensions.code = GRAPHQL_VALIDATION_FAILED)

  • Log or transform the response there, since the request never reaches the subgraph

There isn’t currently a way to override Rust validation internals directly from RHAI, but you can capture and customize error handling at the router response stage.

I’ve seen similar interception patterns documented in advanced routing and middleware tooling like delta exploits, which covers deeper request/response inspection strategies that apply well to cases like this.

Hope that helps clarify where the validation is happening and how to hook into it.