Thanks for fixing them so quickly!

fix -1 to remove a debug tap> that got in the release

hello, thanks, can you open an issue with a repro example please?

https://github.com/wilkerlucio/pathom3/issues/128

ah, sorry, I just realized you are trying to use core.async there, have you imported the promesa bridges library? https://github.com/wilkerlucio/promesa-bridges

Pathom 3 uses Promesa (isntead of Core.async) as the async manager tool, the promesa-bridges can make core.async compatible with promesa

please let me know if that's the case, or if its something else

I didn't include the imports in the example but I do use [com.wsscode.promesa.bridges.core-async]

The async resolver works as long as the resolver has an input that depends on something in the placeholder.

I'm feeling more confident this is a bug in pathom and I've updated the issue example to include imports and more queries to show the problem.

thanks, the example looks great, I'll have closer look later today

sorry the delay, a quick update I can confirm the issue when using go blocks in the scenario that you described

I tested doing the same using promesa futures, and in this case it seems to work fine, I'll have to look further to understand what's causing the distinction

post a detailed response in the issue https://github.com/wilkerlucio/pathom3/issues/128

this seems to be something weird with the Github implementation, Pathom GraphQL integration leverages the types to allow some polymorphic queries with ease, but seems like Github is not happy with that... here is the query that Pathom generates for this case:

query {
  __typename
  ... on Query {
    viewer {
      __typename
      ... on User {
        repositories(first: 10) {
          __typename
          ... on RepositoryConnection {
            edges {
              __typename
              ... on RepositoryEdge {
                node {
                  __typename
                  ... on Repository {
                    name
                    issues {
                      __typename
                      ... on IssueConnection {
                        totalCount
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

I wanna investigate closer where the real problem is, up to some level it works, but after it seems to break (just asking the name from viewer works fine for example)

Yes, it breaks when walking into the :gh.Repo/issues edge and asking for the totalCount. Up to that point I didn't have any issues so far.

I think a way to improve that on Pathom side is to avoid using ... on Type when the attribute is targeting the same type as the current context

(I tried removing the ... on IssueConnection part and it did the trick to fix it)

https://github.com/wilkerlucio/pathom3-graphql/issues/14

Thanks @wilkerlucio. Glad to have alerted you of the issue. I'm looking forward to making use of the GraphQL stuff in Pathom 🙂

I'll try to get to that later today, I have already an idea on how to fix it 🙂

@wilkerlucio thank you, sir 🙏 I will experiment some more with the GH API and let you know if there are other surprises.

@alex.sheluchin since you playing with Github, I just made a fix to root entries (old ident-map), and updated the example on Github to allow a query like this to work:

(p.eql/process env
  {:github.User/login "wilkerlucio" :github.Repository/name "pathom3"}
  [:github.Repository/homepageUrl])

Hey @wilkerlucio, I'm trying to make the root entries example you showed work, but not quite getting it. I'm presuming in Pathom3 it's basically the same as Pathom2? ie the wrapper function to build the ident as recommended in the Pathom2's https://blog.wsscode.com/pathom/v2/pathom/2.2.0/graphql/fulcro.html#MultiInputIdents still applies?

@alex.sheluchin yes, but a bit different, in Pathom 3 we can now send root data much easier than we could in Pathom 2, the think about root entries mapping is that you can access GraphQL entry points without using the entry points, so you can for example provide a user login and ask for user data (instead of nesting over user(login: ...))

the code from the linked example, plus the

(p.eql/process env
  {:github.User/login "wilkerlucio" :github.Repository/name "pathom3"}
  [:github.Repository/homepageUrl])

but about wrapping funcitons, no need to make them nowadays

that syntax doesn't even work anymore, idents can only send a single value, you can now use placeholders to send multiple data points, but there are also other options as: 1. second argument in p.eql/process to send data to the root 2. if using boundary interface, you can send the request as: {:pathom/entity {:entity/data "foo"} :pathom/tx [:query]}

@wilkerlucio I think I have something wrong with my setup right now. All queries just give me:

#object[java.util.concurrent.CompletableFuture 0x35e53559 "rejected"]

#object[clojure.lang.Var$Unbound 0x64a74b92 "Unbound: #'com.wsscode.pathom3.graphql.demos.github/env"]

Execution error (AssertionError) at com.wsscode.pathom3.connect.indexes/register-mutation (indexes.cljc:194).
Assert failed: Tried to register duplicated mutation: com.wsscode.pathom.viz.ws-connector.pathom3/request-snapshots
(nil? (com.wsscode.pathom3.connect.indexes/mutation indexes op-name))

from viz you can use the new panel below the query to provide initial data

can you give a full example of the thing you see? are you using JVM or Browser pathom ?

I am on JVM, just following the example in com.wsscode.pathom3.graphql.demos.github.

The modification I've made is here:

(defn make-env []
  (-> {}
      (p.gql/connect-graphql
        {::p.gql/namespace        "github"
         ::p.gql/root-entries-map {"repository" {"name"  ["Repository" "name"]
                                                 "owner" ["User" "login"]}
                                   "user"       {"login" ["User" "login"]}}}
        request)
      (p.connector/connect-env {::pvc/parser-id ::env
                                ::p.connector/async? true})
      ((requiring-resolve 'com.wsscode.pathom.viz.ws-connector.pathom3/connect-env)
       "gql-github")))

Execution error (AssertionError) at com.wsscode.pathom3.connect.indexes/register-mutation (indexes.cljc:194).
Assert failed: Tried to register duplicated mutation: com.wsscode.pathom.viz.ws-connector.pathom3/request-snapshots
(nil? (com.wsscode.pathom3.connect.indexes/mutation indexes op-name))

Removing the call to p.connector/connect-env from make-env does allow me to use that root entry query from Viz.

No luck in my REPL though. I must be missing something basic about how to use it.

Sorry @wilkerlucio, gotta be something on my end. I've set up reveal for tap> and now I can see the responses properly, and indeed the root entry query works! As for Viz, I didn't realize that bottom Entity Data window was for that purpose. It makes sense now. Appreciate your explanation. I will test a bunch of other GH queries and will let you know if anything doesn't work - hopefully stuff that isn't just related to my setup 🙂

I see you are setting up the connector with ::p.connector/async? true, unless you using the async runner, that will make the thing fail

also, the last line, the requiring-resolve is also adding the connector, so that's adding the connector twice, which will give the error of duplicated things you see

using the require-resolve is a way that I do it so I don't have to :require the viz namespace (makes easy to put in/out)

nothing available at this time

but a summary: in general the resolvers should work fine, attention need to be taken if use stuff from env on the resolvers, also plugins would rewrite some rewriting because the entry points are different now

on resolvers: if I read it correctly, input specification changed a bit as well, right?

yes, minor change, they changed from sets to vectors (EQL to be more precise, now that they accept nested inputs)

writing a function to convert one to another is trivial (except on the case of env usage, then it needs to figure the alternative on Pathom 3)

Thank you for the summary!