Schema error handling on OpenApiProvider

[Thorium]

If there are any errors in schema, the OpenApiProvider just gives up:

SwaggerProvider/src/SwaggerProvider.DesignTime/Provider.OpenApiClient.fs

Line 74 in 4f76f3c

failwithf "Schema parse errors:\n%s"

...which is maybe good behaviour if you can actually fix the schema. But in many cases you are the user, so you can't. Also you cannot easily copy the error. The parser itself will response both a-partially-read-schema and the errors.

So maybe a better way to handle the error case on partial-succeeded-schema, would be creating an "Errors"-property to the root-type and save those as a list of properties, or to xml-comment.

Just a pseudo, something like this:

if diagnostic.Errors.Count > 0 && schema = null then
    failwithf "Schema parse errors:\n%s"
elif diagnostic.Errors.Count > 0 then
    let errorsResponse = ProvidedTypeDefinition("Errors", Some typeof<obj>)
    errorsResponse.AddMember(ProvidedConstructor([], empty))
    errorsResponse.AddMembers(fun () ->
        diagnostic.Errors |> Seq.map (fun e -> sprintf "%s @ %s" e.Message e.Pointer)
        |> Seq.toList |> List.map (fun e ->
            ProvidedProperty(e,typeof<unit>, getterCode = <@@ () @@>) :> MemberInfo
        )
    )
    errorsResponse.AddXmlDocComputed(fun () ->
        diagnostic.Errors
        |> Seq.map (fun e -> sprintf "%s @ %s" e.Message e.Pointer)
        |> String.concat "\n")
    ty.AddMember errorsResponse

//and then continue like nothing happened....
let defCompiler = DefinitionCompiler(schema, preferNullable)

[sergey-tihon]

Generally I am OK with this change...Just not sure about most useful format.
What about Errors:string list and allow user work with errors as with data?

[Thorium]

I'm not sure about the format either, that's why this is a question, not PR :-)
A few points:

• Current implementation is rendering the provider un-usable on any error
• Some schemas may have .Errors-property for business scenarios that should not be messed with technical errors. So basically SchemaReaderErrors would be better.
• But the errors should be clearly visible. ".S" is far away in the property list, so that's why Errors would be better. Or some note to top-level XML-comment?
• Schema reader errors are design-time things, so I was thinking user experience like this:
  myProvider.Errors.[0].``There is an incorrect character in $ref/item/data/my^item``

[sergey-tihon]

Agree with SchemaReaderErrors name.

But the errors should be clearly visible. ".S" is far away in the property list, so that's why Errors would be better. Or some note to top-level XML-comment?

It should not be an issue. We can add it to root level PetStore. SchemaReaderErrors on the same level where we add client for communication SchemaReaderErrors.Client. All other provided type definitions can moved deeper (like PetStore.Types.*)

XML comment also good idea. So it may look like

type OpenApiReaderError = {Messag:string, Position:string}

type ProvidedType
   /// <summary>OpenApi Reader Errors:
   /// - External reference cannot be loaded (postition)</summary>
   member x. SchemaReaderErrors() =
      [{Message="External reference cannot be loaded"; Position="position"}]

I was thinking user experience like this:
myProvider.Errors.[0].There is an incorrect character in $ref/item/data/my^item

This experience is also possible, but I believe that there should be an easily copy error message or position to google it, report an issues, find exact position in schema and fix, etc.

In number of error is large you may want to process them somehow

PetStore.SchemaReaderErrors
|> List.filter (fun x -> not <| x.Message.Contain("$ref"))
|> List.sortBy (fun x -> x.Position)
|> List.iter (printfn "%A")