JustinCanton / Geo.NET

A lightweight method for communicating with the multiple online geocoding APIs.
MIT License
13 stars 8 forks source link

Here not returning status code when unsuccesfull call #83

Closed ollie10 closed 10 months ago

ollie10 commented 11 months ago

Hi @JustinCanton , I was making some tests for the HERE connector.

I have got the error: "The call to Here did not return a successful http status code. See the exception data for more information." but no Inner Exception is shown. This leads to that you don't know if your API key is invalid, if you exceeded the limits, if you sent a wrong parameter etc. etc. and it is impossible to debug what's going on.

Here the exampe: https://ibb.co/Y7BwsFf

Many thanks

JustinCanton commented 11 months ago

Hi @ollie10,

I apologize. I have been off for a little while now. I will try to tackle this issue next week.

Its interesting that this is happening. I honestly believed I had all of the cases covered and they would have an inner exception. Can you send me your request data you are using?

Thank you

JustinCanton commented 11 months ago

Hi @ollie10, I checked the code again, and I realized that for that specific error, there is no internal exception. It is in the Data object of the exception. Inside that, there should be the full uri, the status code, and the response body image

This makes sense given the exception message you got: "The call to Here did not return a successful http status code. See the exception data for more information."

Can you please try to reproduce and check to see if that data is there, and if you can resolve your problem using that information.

Justin

ollie10 commented 11 months ago

Hi @JustinCanton you are right, that's what I see:

It seems the call is not passing the language.

My call is made like this

GeocodeParameters parameters = new GeocodeParameters() { Query = address, Limit = 1, Language = culture };
GeocodingResponse response = await _hereGeocoding.GeocodingAsync(parameters);
return ParseResponse(response, GENERIC_ADDRESS_TYPES);
JustinCanton commented 11 months ago

Hi @ollie10 ,

We do have a test case covering this. (https://github.com/JustinCanton/Geo.NET/blob/develop/test/Geo.Here.Tests/Services/HereGeocodingShould.cs#L206C18-L206C18) It does seem to be working correctly.

It uses the name value of the culture:

if (parameters.Language != null)
{
    query = query.Add("lang", parameters.Language.Name);
}
else
{
    _logger.HereDebug(_resourceStringProvider.GetString("Invalid Language"));
}

What is the value of culture you are passing?

Justin

ollie10 commented 11 months ago

Normally it could be one between es-UY, es-AR, en-US or similar. Always Spanish or English with a country between latin america or united states

JustinCanton commented 11 months ago

Interesting. Well can you try doing culture.Name for me and see what the value is when the request fails? Maybe using the Name property isn't the right thing to do.

ollie10 commented 11 months ago

I think I understood the problem, it arises when you use CultureInfo.InvariantCulture as Culture, no problem with es-ES or en-US apparently, that's becuase culture.Name of CultureInfo.InvariantCulture is empty.

But the root problem is another: both methods GeocodeAddress and ReverseGeocodeCoordinates requires a culture which is not a mandatory parameter according to their documentation

JustinCanton commented 11 months ago

@ollie10, the Language parameter isn't required in the parameters object. It can be left as null, and it will not be sent to Here:

var parameters = new GeocodeParameters() { Query = "123 main street", Limit = 1 };
var results = await _hereGeocoding.GeocodingAsync(parameters).ConfigureAwait(false);

That said, the InvariantCulture and other empty cultures are an issue. I will fix that issue.

Justin