Surface deep HTTP errors

[BlackHawke007]

Motivation

The SDK suppresses HTTP errors from the KAI back-end servers that could be useful for the SDK user to know about and act on.

For example, when you specify bad arguments in the query parameter list of the delivery client and the client is executed - nothing is returned and you receive a very unhelpful LINQ-exception of the "source is null" kind. However, when you enable the source-debugging link on Visual Studio and laboriously trace the call down to the DeliveryClient.cs level, then you can see the pertinent details of why the HTTP call failed.

Proposed solution

If the response from the backend service is a validation error, return that error all the way up to the point of contact (eg. var list = await deliveryClient.GetItemsAsync(parameters); ).

More fundamentally, don't send back a null object - the client always breaks because the attached LINQ code expects a source. At least throw a better exception.

Additional context

This image show where inside the Kontent.Ai.Delivery.DeliveryClient.cs the pertinent error and details are available.

[pokornyd]

hello and thank you for the submission!

the sub-optimal error handling in the SDK is something we're aware of and it's actually one of the motivators for the ongoing modernization effort, which aims to unify both successful and failing responses, minimize throwing and propagate errors to the result whenever possible.

this is a part of a broader modernization story for our .NET stack, including management SDK and related model generators, with the delivery SDK being the first updated. you can expect a beta release in the upcoming weeks, along with many other changes (often breaking due to the extensive nature of the modernization) aimed at improving the developer experience for .NET users