Adding an explanation to the StateException regarding the possible reasons for the access token being missing.

[luckpoint]

Checklist

• [X] I agree to uphold the Code of Conduct.

Description

I am seeking an explanation for why the access token might be missing. The StateException does not provide detailed information.

Here is an excerpt from Auth0#renew:

$response = $this->authentication()->refreshToken($refreshToken, $params);
$response = HttpResponse::decodeContent($response);
if (! isset($response['access_token']) || '' === trim($response['access_token'])) {
  $this->clear();
  throw \Auth0\SDK\Exception\StateException::failedRenewTokenMissingAccessToken();
}

The causes of errors:

• Rate limit error (429)
• Denial of access through api.access.deny() in Actions (500)
• Other reasons

A possible solution would be to modify the methods in StateException to accept and set a status code. This way, the application could catch a StateException and retrieve its statusCode. Or create a separate method and message for each cause.

[evansims]

Hi @luckpoint! 👋 Is this an actual issue being encountered or a hypothetical situation we're trying to avoid?

Strictly speaking, those conditions shouldn't ever occur. The host application's HTTP client library captures network request failures like you've described (429s, 500s, etc.). Under those circumstances, those libraries will throw Psr\Http\Client\ClientExceptionInterface exceptions for any response that isn't a 200, 201, or other success code.

The SDK catches those ClientExceptionInterface exceptions. It wraps the exceptions and throws an Auth0\SDK\Exception\NetworkException for the host application to intercept. These NetworkException objects do encapsulate the original ClientExceptionInterface. Applications can evaluate the exception to determine the cause of the network failure using Exception::getPrevious().

As such, failures to retrieve access tokens during token refreshes due to network conditions will never raise a StateException. Instead, It will throw a NetworkException, which includes the reason for the exception, at least as far as what the underlying HTTP library provided.

Beyond that, the SDK is purely working with how the API responds to us, so we'd be unable to answer why the API responded unusually. Certainly, nothing more than would already be available in tenant logs.

If this is a real issue being encountered, was anything relevant found in the tenant logs to explain it?

[luckpoint]

@evansims Thanks for your detailed answer. I understand.