Automattic\WooCommerce\Api\Infrastructure
GraphQLControllerBase::handle_request
Handle an incoming GraphQL request.
Resolves the principal first so debug-mode / introspection checks can consult it from inside both process_request() and the top-level exception formatter. When resolve_request_principal() itself throws (e.g. an InvalidTokenException from a plugin's PrincipalResolver), $principal stays null and the resulting error response carries no debug info — by design, since the caller failed to authenticate.
Method of the class: GraphQLControllerBase{}
No Hooks.
Returns
null. Nothing (null).
Usage
$GraphQLControllerBase = new GraphQLControllerBase(); $GraphQLControllerBase->handle_request( $request ): \WP_REST_Response;
- $request(WP_REST_Request) (required)
- The REST request.
GraphQLControllerBase::handle_request() GraphQLControllerBase::handle request code WC 10.9.1
public function handle_request( \WP_REST_Request $request ): \WP_REST_Response {
$principal = null;
try {
$principal = $this->resolve_request_principal( $request );
return $this->process_request( $request, $principal );
} catch ( StatusResolverFailedException $e ) {
// Resolver threw on one of the decision points inside
// process_request(). Produce a clean 500 without re-invoking
// the (broken) resolver.
return $this->build_resolver_failure_response( $e, $request, $principal );
} catch ( \Throwable $e ) {
$output = array(
'errors' => array(
$this->format_exception( $e, $request, $principal ),
),
);
$default = $this->get_error_status( $output['errors'] );
try {
$status = $this->pick_status( $default, $output, $request );
} catch ( StatusResolverFailedException $e2 ) {
// Resolver threw specifically when handed the synthetic
// errors shape from this catch block. Fall through to the
// fixed 500; do not loop back into the resolver.
return $this->build_resolver_failure_response( $e2, $request, $principal );
}
return new \WP_REST_Response( $output, $status );
}
}