Im not an expert, but maybe :pco/input needs to be a vector? [:acme/feed]. And the nested map would go to the resolve function.

I never tried union as an input for a resolver, there might be some issue there

on a quick look at the resolver it already looks off:

#com.wsscode.pathom3.connect.operation.Resolver{:config #:com.wsscode.pathom3.connect.operation{:input [#:acme{:feed {: [:],
                                                                                                                      : [:
                                                                                                                                   :,
                                                                                                                      :acme.video/id [:acme.video/title]}}],
                                                                                                :provides {:foobar {}},
                                                                                                :op-name foobar,
                                                                                                :output [:foobar],
                                                                                                :requires #:acme{:feed {nil {nil #:acme.video{:title {}}}}}},
                                                :resolve #object[repro_caleb$eval56069$fn__56070
                                                                 0x69b15a88
                                                                 "repro_caleb$eval56069$fn__56070@69b15a88"]}

see the :requires, it has some nils over the place

@U066U8JQJ Thanks for looking into that. Do you know whether or not there is any point specifying unions queries as outputs?

@U0FT7SRLP Thanks for jumping in to help out. Pathom3 supports EQL queries with union syntax and I’m trying to use that syntax in the input. It looks odd but, but the map-within-map is valid when used with p.eql/process https://pathom3.wsscode.com/docs/eql/#union-queries

Looks like it’s not supported in the input however.

on the output it does handle properly, but I don't remember actually trying it

I’ve used it on outputs for a while now and haven’t noticed anything odd

the thing is that the input is using a specialized function to generate the shape descriptor (while output uses the default query->shape-descriptor, which supports unions)

because the input shape descriptor generator has also the job of separating the optionals

not yet, but that's something I think could be useful, its easy to add an extension point, maybe one after the graph is ready could be a start?

altough, if you found some generic way that could be used in general, I would rather include it in the library

I just implemented what you suggested in another thread, merging sibling with same run-next. Solve my issues but need to run more test to see if it’s not breaking anything

but I'm happy to learn you are figuring it out, its great to have more people getting familiar with those internals 🙂