Generated F# client throws NullReferenceException if the server returns an empty response

Hi,

I fell over this by accident when I pointed the client at the wrong server endpoint - if the server doesn’t return any response content (for example, because it has returned a 404 status), then I get a NullReferenceException thrown from

https://github.com/Zaid-Ajaj/Snowflaqe/blob/2da41cfcfcf95cfa711cf676767e55adb485a3da/src/CodeGen.fs#L1088

because responseJson is null.

[Zaid-Ajaj]

it just seems ‘unfortunate’ when things like serialization library specific exceptions escape

Using the current implementation shouldn’t result in any JSON deserialization errors. That is when the response is actually JSON 😂

I have some tests for existing generated C# REST/OpenApi clients that are created by NSwag, which use a combination of interfaces

I am thinking of using a mocking library at the end but I don’t want to mock methods at the HTTP level and return JSON responses (what MockHTTP does) because the generated client deals with typed inputs and responses.

Consider this piece of code that uses the generated client:

let process (client: GraphqlClient) : int = 
  match client.GetUser() with
  | Some user -> 
      match client.GetData { user = user.Id } with
      | Some data -> 42
      | _ -> -1
  | _ -> -1

this process function takes the GraphQL client as input and I you as a user want to test it. Then without refactoring the code, you should be able to do the following (to be implemented):

let interceptor = GraphqlInterceptor()
// provide here the test responses
interceptor.GetUser(fun () -> Result.Ok testUser)
interceptor.GetData(fun input -> Result.Ok testData)
// create a client that uses the interceptor
let testClient = interceptor.BuildClient()
// act
let output  = process testClient 
Expect.equal output 42 "The output is correct" 

Of course, the GraphqlInterceptor would be a class that is also generated that uses a mocking library under the hood.

This is all to be implemented of course. What do you think about this approach? 🤔

[Yakimych]

Sure, I understand the problem from this perspective.

It is a matter of configuring the tool correctly.

I don’t think this is fair, however. The tool may be configured correctly for generating code statically, but in a real-world scenario the generated code may be run against many different deployed versions of the same API (master, feature branches, staging, live, etc.). Introspecting all of those might not always be possible (introspection disabled in Live, for example). We use it for tests btw.

I think this is not sufficient to check for the error because non-2xx status codes are still valid GraphQL responses.

Yes, definitely. It might still be helpful though - better than a generic NullReferenceException for sure. Even something like wrapping the exception with our own “Please check that the runtime URL is set correctly” message might save some time debugging the issue runtime.

In any case, just thought I would chime in with some practical experiences. Just thinking ahead - unfortunately achieving the equivalent of “type safety” in the DevOps world is not really feasible, so misconfiguring CI/CD pipelines and deployment scripts will happen. And when it does, there is a huge difference between getting a NullReferenceException from a failed test, and e.g. Double-check that this endpoint responds as expected: {endpoint} message.

Otherwise, I don’t have any good suggestion for a “fix” either, so maybe we can consider closing this issue in that case?