Fork me on GitHub
#pathom
<
2021-02-16
>
nivekuil03:02:23

trying to implement the above, but not sure what's wrong

(defresolver response [{:keys [uri]}]   {::pco/output [::response]}   (p/let [response (http/get uri)]     {::response response}))  (def smart-map (psm/smart-map (pci/register response) {:uri ""}))  (::response smart-map) => nil
with the log line: WARN :com.wsscode.pathom3.connect.runner/invalid-resolver-response - {:com.wsscode.pathom3.connect.operation/op-name app.resolver.uri/response, :response #object[java.util.concurrent.CompletableFuture 0x22b2c2f4 "pending"]} the response does appear to be correctly fetched within the resolver if I log/spy it

souenzzo12:02:34

@kevin842 you are using an async (returns a CompletableFuture) resolver with a sync runner (smart-maps) For now, as far i know, to async you need to use the "process" with env+query

wilkerlucio13:02:36

@kevin842 you can't use async with smart maps, you need to use the async EQL process for this

nivekuil15:02:06

ah thanks. don't see it mentioned in docs, will it be added someday?

nivekuil15:02:08

nvm it is mentioned, but not too explicitly: To async, there is only the EQL interface

Chicão15:02:04

Hi, when I invoke my logout mutation and pass the values to it, inside it I see the namespace/request instead of the value, does anyone know why this happened?

(p.eql/process env
               [`(logout {::request request
                             ::url url
                             ::cookie-store new-c})])

wilkerlucio15:02:37

its because you are using the backtick to expand, you have to use ~ before the values to get them there

wilkerlucio15:02:47

(p.eql/process env
               [`(logout {::request ~request
                             ::url ~url
                             ::cookie-store ~new-c})])

👍 1
nivekuil16:02:39

will pathom ever walk the same node twice? e.g. A->(B | C) C->target B->A' will pathom ever cycle back to A from A'? I have an alias resolver from A'->A but it seems it never walks back to A, to retry the A->C->target path again starting from A'

dehli16:02:43

I believe the default behavior is that it won’t b/c the resolver’s response is cached for a specific input

nivekuil16:02:42

that's a good point, but A' would have a different value than A (and I wouldn't want it to loop if they were equal), and I think the cache is keyed based on the resolver params?

nivekuil16:02:36

tried setting ::pco/cache? false on everything, no diff

dehli16:02:13

Ahhh, so in your example A' would go through the resolver A but it’s a different “id” from what the initial A resolver was called with

nivekuil16:02:27

yeah, an alias-resolver creates that path from A' to A, i.e. A with the value of A'

wilkerlucio17:02:47

yes, Pathom may duplicate the same node in different points of execution, this may happen with OR cases

wilkerlucio17:02:58

but no cycles

wilkerlucio17:02:03

the planner never has cycles

nivekuil17:02:01

got it. I just ended up explicitly specifying the connection. this is super cool.. I think I am actually going to try to replace my entire backend with pathom :p

nivekuil17:02:14

the i/o parts at least

wilkerlucio20:02:00

yup, I keep doing that, a lot of Pathom Viz UI work is also supported by pathom inside 🙂

Chicão16:02:55

I had this mutation and when I invoke it, got this error Can't find a path for :async

(pco/defmutation logout [{::keys [request url cookie-store] :as logout-input}]
  (http/post url (assoc request :cookie-store cookie-store))
  logout-input)
how I called the mutation
(p.eql/process env
               [(logout {::request request
                             ::url url
                             ::cookie-store new-c})])
I need to use something like async runner to mutation with http calls?

dehli16:02:04

pathom3 uses https://cljdoc.org/d/funcool/promesa/6.0.0/doc/user-guide. I’m not sure which http library you’re using but if it returns a promise you can do something like:

(:require [promesa.core :as p])

(pco/defmutation logout ...
  (p/let [response (http/post url)]
    ;; Use response as you'd like

👍 1
Chicão16:02:32

nice, thanks for help me

👍 1
dehli16:02:51

if the lib uses core.async, then you can look into https://github.com/wilkerlucio/promesa-bridges

👍 1
wilkerlucio17:02:13

@UL618PRQ9 I just noticed the way you are calling the mutation is wrong

wilkerlucio17:02:27

you removed teh backtick thing

wilkerlucio17:02:33

and the mutation needs to be as data

wilkerlucio17:02:43

in the way you doing, you are invoking the mutation and returning is result as a query

wilkerlucio17:02:17

the code we talked before was right, as:

(p.eql/process env
               [`(logout {::request ~request
                             ::url ~url
                             ::cookie-store ~new-c})])

wilkerlucio17:02:28

☝️ this and what you are doing are not equivalent

Chicão17:02:18

Wow, thanks a lot!

Chicão17:02:33

it's worked.

🎉 1
nivekuil18:02:03

debugging with pathom viz, I see that a node I expect to succeed has this attached to it:

:com.wsscode.pathom3.connect.runner/node-error  #object[Object [TaggedValue: unknown, #error {  :cause "Insufficient data"  :data {:required {:app.pathom.uri/response {}, :app.pathom.uri/response-url {}}, :available {}}
but scrolling down, I do see valid data in node-resolver-input:
:com.wsscode.pathom3.connect.runner/node-resolver-input  {:app.pathom.uri/response ...   :app.pathom.uri/response-url ...}

nivekuil18:02:02

not sure what the cause is.. the nodes go like response -> response-url -> OR -> (node with error | OR | another node)

nivekuil18:02:36

the node with error is reachable through some queries but not others, even though they should follow the same initial path.. hm. seems I have to explicitly specify another attribute in the query, but I would expect pathom to be able to get to it regardless? should it be necessary to "hint" the planner like this?

dehli21:02:02

can you post what the failing query looks like and the relevant resolvers (pseudocode is fine)

nivekuil15:02:24

let me demonstrate a different, maybe related planner behavior, with viz nodes:

nivekuil15:02:00

the top picture is with the bottom-left ->view resolver with a higher priority. it takes that path, realizes it doesn't have enough info, and just dies, neglecting the middle response->response-url path

nivekuil15:02:29

bottom picture doesn't set a priority on the bottom-left ->view, it takes the proper path and succeeds

nivekuil15:02:43

it seems like the planner is not capable of backtracking in general?

nivekuil18:02:07

tested the latest commit and it seems both cases I ran into here now work as expected. thanks @U066U8JQJ ! :D

wilkerlucio18:02:06

there was some planning fixes that landed yesterday, I guess they fixed your case too 🙂

wilkerlucio18:02:29

the error handler does backtracking

wilkerlucio18:02:37

if you find any other weird cases, please let me know

👍 1
wilkerlucio18:02:15

@kevin842 another thing that may be interesting to you, if you look in the meta, in the node-stats key, if there is any error, it will have a key called "nodes-with-errors", this is a more "global" way to find any errors, you can use this a way to ask the question: did any error happen?