This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-05
Channels
- # announcements (16)
- # babashka (10)
- # beginners (80)
- # calva (18)
- # cider (10)
- # clojure (96)
- # clojure-austin (1)
- # clojure-europe (52)
- # clojure-france (6)
- # clojure-germany (2)
- # clojure-italy (4)
- # clojure-nl (4)
- # clojure-seattle (3)
- # clojure-spec (4)
- # clojure-uk (25)
- # clojurescript (97)
- # community-development (2)
- # cursive (7)
- # datomic (13)
- # figwheel-main (5)
- # fulcro (13)
- # inf-clojure (1)
- # jobs (3)
- # off-topic (33)
- # pathom (10)
- # polylith (8)
- # re-frame (7)
- # reitit (8)
- # releases (1)
- # reveal (2)
- # ring (4)
- # ring-swagger (1)
- # sci (6)
- # shadow-cljs (102)
- # slack-help (1)
- # spacemacs (28)
- # tools-deps (9)
- # vim (1)
- # xtdb (3)
This code results in an internal guardrails exception in the latest Pathom3. I'm not sure if specifying a key path in ::pco/input
is proper usage. In fact, if I trim the path in each of the resolvers to a single key (ie, :ui/query
and :pql/query
) , pathom is happy. Further, if I remove one of the resolvers, pathom is happy.
from your description it seems a bug somewhere, what happens if you disable guardrails? the result is what you expect?
I haven't tried disabling guardrails - I'll give that a shot in an hour or so
With guardrails disabled, Pathom3 has throws a stack overflow. This is the first many frames
(sorry for the delayed reply - I got distracted yesterday)
@markaddleman fixed https://github.com/wilkerlucio/pathom3/commit/d9a950c96f3fe3115a54679228dbf92c2ca06c9b
Fantastic thanks!
the issue was a recursion in the nested thing, the edge of ui-query->time-range
input was the same key as the output (`:query/timeRange`)
that drover the planner to do an infinite recursion, but fixed now
thanks for testing and bringing those cases to the light 🙂