Explicitly mention the endpoint in connection errors

[klolos]

Is your feature request related to a problem? Please describe.

We have been using the C++ STS client to retrieve credentials for our application running on EKS via the AssumeRoleWithWebIdentity() call. When the client fails to connect to the STS endpoint, the error it returns does not seem to contain information about the exact endpoint it tried to connect to. For example, in the 1.8.137 version of the client, when trying to connect to a region whose endpoint it cannot resolve, the error message is the following:

curlCode: 6, Couldn't resolve host name

We need to be able to retrieve the endpoint for a failed call so we can log it, since this is very important in order to troubleshoot networking and connectivity issues.

Additionally, the way the client determines the default AWS region, which it in turn uses to construct the STS regional endpoint, has changed between different versions of the client, making it harder to reason about its exact value.

Describe the solution you'd like

The error returned by the client should explicitly mention the endpoint it attempted to connect to, either as part of the error message or in a different dedicated field.

Describe alternatives you've considered

We have tried enabling logging in the SDK, which does output the endpoint in the logs. However, we would like to be able to explicitly have access to the endpoint in our code, in order to include it in our own logs and be able to produce useful error messages.

We have also considered explicitly selecting the region the client will use via the ClientConfiguration object, which would give us some control over the endpoint. However, this would still not allow us to know the exact endpoint with certainty, and would additionally prevent our code from behaving uniformly with other AWS components due to potentially selecting a different region.

As a sidenote, we see that the exception name for this error is also empty. Could some relevant information about the error be included in this field as well?

[klolos]

Did you get a chance to look into this? It did bite us in production, connectivity issues are common, and it really helps to have full/accurate logs when identifying problems.

I can give it a try myself, prepare and contribute a PR. Do you have any pointers on how I could start attacking this? Any guidance / initial ideas are more than welcome.

[jmklix]

Thanks for the feature request, this is something that we want to improve. I don't know when we will be able to add this to the sdk