As a developers, API errors should be easier to get to and get the full details

[sebastienlevert]

No description provided.

[sebastienlevert]

Related to microsoftgraph/msgraph-sdk-go#510

[baywet]

We already generate the error types based on the description. What's missing is mapping a field of that type to the "standard error message" for the error/exception in the runtime, so it's easier to get an actionable message.
For that we'd need an extension that tells us "this is the property you should get the message from".
We could either have that extension contain some jq/jamespath/jsonpath expression (but parsing it and handling complex cases might be a lot of work) or just scan all sub-properties in the error type for that "marker extension" (but then we need to define what happens if we find multiple entries).

@darrelmiller to help with the technical specification of that extension.

[darrelmiller]

1. If there is a x-ms-primaryErrorMessage: true annotation in the error schema, use that property as the message in the native exception object
2. Otherwise, put the HTTP reason phrase in the exception message
3. Add type of the exceptions that will be thrown in the request executor method comments

components:
  schemas:
    ODataError:
      type: object
      properties:
        code:   
          type: string
        message: 
          type: string
          x-ms-primaryErrorMessage: true

[Ducki]

Does the x-ms-primaryErrorMessage field also get recognized if it is on an inherited property further up the "chain"?

We have a ValidationProblem type, which inherits from HttpValidationProblem, which inherits from ProblemDetails. On the ProblemDetails object, we declare the detail property as the primary error message. Still, the exception message is Exception of type '[…]ValidationProblem' was thrown., the actual error is nowhere within the exception object.

[baywet]

The part that projects schemas to types should recognize the extension on the property and add the information to the property.
However the part that emits the path to that property only looks at the current type, not the inheritance chain.
This should be easy to adapt by recursively calling the method on the parent types.

kiota/src/Kiota.Builder/Writers/ProprietableBlockExtensions.cs

Line 13 in 8e3e8db

internal static string GetPrimaryMessageCodePath<TBlockKind, TBlockDeclaration>(this ProprietableBlock<TBlockKind, TBlockDeclaration> block,

Don't hesitate to submit a pull request!