Automattic\WooCommerce\Api\Infrastructure

GraphQLControllerBase::handle_requestpublicWC 1.0

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() 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 );
	}
}