Closed Zaid-Ajaj closed 3 years ago
Pulled down 1.7.0 and re-generated, getting an NRE on x.organization
Hmm this is using the fsharp target as I can see 🤔 can you please provide more info for me to debug? I need the module of the generated types for GetPullRequests
as well a sample JSON returned from the GraphQL endpoint (you can get that by modifying the GraphqlClient
member GetPullRequests
and have print the JSON to the console or to a file before it is actually deserialized. (This seems to be a deserialization issue)
getting an NRE on x.organization
This is kinda weird actually. An NRE should never occur because we are only using records, unions, options and lists. Can you please run printfn "%A" res
before pattern matching against the results?
Ok null
I'll work on your previous comment.
It's a 200 back from GHE w/the errors payload, so it doesn't try to deserialize into GraphqlErrorResponse
.
It's a 200 back from GHE w/the errors payload, so it doesn't try to deserialize into GraphqlErrorResponse.
Should be fixed as of v1.7.1 now the generated client will check for potential errors even when the HTTP response is 200 (Only on F# code gen target like the one you are using)
Compile error type Organization
is duplicated
Organization doesn't directly have an author from what I can tell.
The Author option references the type OrganizationAuthor which I think was supposed to be the name of the line #33 type?
I just fixes is particular issue and now the query above is properly validated when using incorrect inline fragments.
Compile error type Organization is duplicated Organization doesn't directly have an author from what I can tell. The Author option references the type OrganizationAuthor which I think was supposed to be the name of the line #33 type?
Yeah you are right, looks like one more issue to go, I think I know why this is happening. Thanks a lot for debugging this with me
I feel like I'm bugging more than debugging lol
I feel like I'm bugging more than debugging lol
No, feedback from real use cases are really valuable and I couldn't otherwise fix all of these problems without your input :wink: In any case, I just released another fix for the naming collisions as of v1.7.3 and this time I've added integration tests for the Github schema that generate and compile a project based on your GraphQL queries so now we know for sure it works without accidentally breaking it :smile:
Using an inline fragment with type condition should be validated when used as part of the selection set of a GraphQL object. Sample incorrect query (see this comment)