Clojurians Log v2

sample I made here:

(ns demos.async-mutations
  (:require [com.wsscode.pathom3.connect.indexes :as pci]
            [com.wsscode.pathom3.connect.operation :as pco]
            [com.wsscode.pathom3.interface.async.eql :as p.a.eql]
            [com.wsscode.promesa.bridges.core-async]
            [promesa.core :as p]))

(pco/defmutation sample []
  (p/resolved {:foo "bar"}))

(def env
  (-> {}
      (pci/register [sample])))

(comment
  @(p/let [foo (p.a.eql/process env [`(sample {})])]
     foo))

Ah sorry, it is a mutation join. Maybe I have a bad resolver

I'm returning what it needs, so it didn't occur to me that a resolver would even be invoked

could be a bug too, so will be nice if we can make a standalone repro

also, Pathom 3 currently doesn't provide "hard limits" for processing (which Pathom 2 does), it could be a time to consider it, I'm still not sure if thats better as a Pathom feature or something for the user to handle (adding a timeout around your process call to ensure it finishes at some point)

a basic mutation join seems to work (with data ready, and fetching after):

(ns demos.async-mutations
  (:require [com.wsscode.pathom3.connect.built-in.resolvers :as pbir]
            [com.wsscode.pathom3.connect.indexes :as pci]
            [com.wsscode.pathom3.connect.operation :as pco]
            [com.wsscode.pathom3.interface.async.eql :as p.a.eql]
            [com.wsscode.promesa.bridges.core-async]
            [promesa.core :as p]))

(pco/defmutation sample []
  {::pco/output [:foo]}
  (p/resolved {:foo "bar"}))

(def env
  (-> {}
      (pci/register [sample
                     (pbir/alias-resolver :foo :bar)])))

(comment
  [@(p.a.eql/process env [{`(sample {}) [:foo]}])
   @(p.a.eql/process env [{`(sample {}) [:bar]}])]
  ;=> [{demos.async-mutations/sample {:foo "bar"}} {demos.async-mutations/sample {:bar "bar"}}]
  )

I’ll see if I can tease it apart into a min repro. This is a new project, and I only have the one test resolver, and two mutations that are called via mutation joins. There is NO resolver that could possibly resolve the data the mutation joins query for, BUT the query MIGHT contain things that the mutations do not always return

I may just stick with pathom 2 for now, but I did want to try 3 out and see how it was going. For this particular app, though, it probably doesn’t have anything new that I want/need (the queries won’t be particularly complicated/deep/involved)

I'm interested in learning whats going on, if you can get a repro I'll be happy to help figure whats going on

OK, I think this exposes my problem:

(ns demos.async-mutations
  (:require [com.wsscode.pathom3.connect.built-in.resolvers :as pbir]
            [com.wsscode.pathom3.connect.indexes :as pci]
            [com.wsscode.pathom3.connect.operation :as pco]
            [com.wsscode.pathom3.interface.async.eql :as p.a.eql]
            [simplymeet.lib.core]
            [promesa.core :as p]))

(pco/defmutation sample []
  {::pco/output [:foo :bar]}
  (p/resolved {:foo "bar"}))

(def env
  (-> {}
    (pci/register [sample])))

(comment
  [@(p.a.eql/process env [{`(sample {}) [:foo :bar]}])
   ]
  ;=> Execution error (ExceptionInfo) at com.wsscode.pathom3.connect.planner/verify-plan!* (planner.cljc:1694).
Pathom can't find a path for the following elements in the query: [:bar] at path [demos.async-mutations/sample]
  )

I expected a not found result

In my case I’m doing a login mutation, and the data that gets resolved is ONLY available from the mutation, but some of it doesn’t come back on login failure

so there is no resolver to “make up the difference”.

yeah, the default mode is strict and wont allow for missing things, but the client can say something is optional, I guess in your case you will prefer to use lenient mode, but otherwise this works:

@(p.a.eql/process env [{`(sample {}) [:foo (pco/? :bar)]}])

the difference is that the client is expressing that :bar is optional, so Pathom 3 wont throw in case its missing

well, at least it isn’t a bug. Thanks for looking