hello, that error message seems to indicate that introspection is disabled, can you send some parts of the giant pile you get when you call the request? introspection is required for Pathom 3 graphql to integrate, since it needs it to figure what's possible to query from that GraphQL API

Poking around I figured that was the case. I’ve requested they enable introspection and hopefully that part of the issue. What I don’t have a good feel for is what it would take to improve the error handling so that pathom3-graphql can report the introspection problem.

Looking at this further, introspection is turned on and that is why the big pile of JSON was coming back from the direct call to the server. The error from Apollo Studio was because I was hitting an intermediate GraphQL server that didn’t have introspection enabled. So, there is something there amongst the ~1500 types that pathom3-graphql doesn’t like.

p.gql/connect-graphql seems to be choking on some of the mutations. The common theme that jumps out is they all have :com.wsscode.pathom3.connect.operation/output [nil] when passed to pco/mutation. Adjusting p.gql/build-indexes to convert those to [nil]s to [] seems fix the problem. (Or, at least doesn’t blow up anymore.) @U066U8JQJ do you have a feel for if this is likely a problem with pathom3-graphql’s parsing or with the GraphQL server’s setup somehow?

Another data point, the mutations that are having issue are returning Boolean and String, at least in most cases.

hi Grant, sorry the delay, having some busy days here, but I think I’ll be able to have a look at it later today, I dont remember doing much testing on mutations so I would not be surprised if there is a bug there

Even with a few bugs, your library is a huge help. Thank you for making it. I’m happy to help with whatever I can, but I’m brand new to GraphQL, so you’d probably have to provide some strategic/design guidance for any code help. I can at least help with any testing you need on changes.

sure, glad to have you testing it, to be honest I dont know that much GraphQL either, at least not as an user, I have read though their docs and specification to see what I need to map, but I never actually used it directly

and I see Apolo and others might change things slightly, so will be nice to catch any of those practical things we may need to adapt

@U0EFQAS4B any chance you have a code-sample of how you fixed this on your end? running into the same issue!

if not, i'll take a stab at it this evening and submit a PR

I have a hack that makes it work. It’s not a fix. I was hoping to actually get a fix in as a PR but haven’t had a chance to work on it. Happy to share, but I don’t have anything posted anywhere at the moment. I can try to get it up this evening though.

sounds good! I'll see when i can get to poking around as well

Hey Tyler, I didn’t get a chance to work on this, but here is the hack that I put it to the parser so I could keep moving. All it does is chunk the error condition. The error is caused by a mutation returning something like Boolean or String. The current parser code turns that into ::pco/output [nil] which the eql library doesn’t like. So if you replace the last from in build-indexes

(mapv pco/mutation (pathom-mutations env'))

(mapv (fn [m]
        (if (= (:com.wsscode.pathom3.connect.operation/output m) [nil])
          (pco/mutation (assoc m :com.wsscode.pathom3.connect.operation/output []))
          (pco/mutation m)))
      (pathom-mutations env'))

Thanks grant!