Fork me on GitHub
#pathom
<
2023-08-23
>
Ben Grabow18:08:30

I think I found a weird bug related to reordering of collections that are nested inputs to a resolver:

(ns pathom-reverse-inputs
  (:require [com.wsscode.pathom3.connect.indexes :as pci]
            [com.wsscode.pathom3.connect.operation :as pco]
            [com.wsscode.pathom3.interface.eql :as p.eql]))
=> nil
(pco/defresolver reverse-inputs
  [input]
  {::pco/input [{:a [:b]}]}
  {:input input})
=> #'pathom-reverse-inputs/reverse-inputs
(p.eql/process
  (pci/register reverse-inputs)
  {:a (list {:b 1} {:b 2})}
  [:input])
=> {:input {:a ({:b 2} {:b 1})}}
Am I correct in assuming this is unintentional? I'll write up an issue if so.

wilkerlucio18:08:14

I remember having this kind of issue before, there is even a helper that checks and reverts the order in such cases, but it might got missed using it somewhere

wilkerlucio18:08:52

because Pathom will reconstruct collections as part of the processing, and for lists to keep the order we need to reverse it at the end of the operation

wilkerlucio18:08:37

I guess there is some case missing in terms of nested inputs

Ben Grabow19:08:13

I can work around it for now, thanks for checking!

Björn Ebbinghaus19:08:16

In Pathom2 there was a helper to sort the output. It was necessary for batch resolvers. https://blog.wsscode.com/pathom/v2/pathom/2.2.0/connect/resolvers.html#_aligning_results

wilkerlucio20:08:47

@U4VT24ZM3 Pathom 3 has that too, but this is a different kind of problem, the result align is for batch when you need to ensure the output list has the same size and positions as the input list

wilkerlucio20:08:54

but here pathom is just reversing the list order