This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-20
Channels
- # adventofcode (47)
- # announcements (3)
- # aws (29)
- # bangalore-clj (3)
- # beginners (63)
- # boot (2)
- # braveandtrue (40)
- # calva (34)
- # cider (37)
- # cljs-dev (8)
- # clojars (3)
- # clojure (45)
- # clojure-europe (2)
- # clojure-france (4)
- # clojure-india (2)
- # clojure-italy (44)
- # clojure-japan (4)
- # clojure-nl (39)
- # clojure-serbia (1)
- # clojure-spec (21)
- # clojure-uk (75)
- # clojurescript (28)
- # cursive (24)
- # data-science (3)
- # datomic (31)
- # emacs (13)
- # fulcro (35)
- # hoplon (21)
- # jobs-discuss (66)
- # nrepl (18)
- # off-topic (72)
- # pathom (35)
- # re-frame (20)
- # reagent (54)
- # shadow-cljs (35)
- # spacemacs (9)
- # specter (8)
- # sql (13)
- # testing (9)
- # tools-deps (21)
- # vim (3)
I've read through the documentation, and part of the code, and I just can't get an exception to actually be thrown when I throw it within a mutation. ::pp/fail-fast?
doesn't do anything, the explicit error handler doesn't do anything. It seems to me like the code in pp/parser
always does try/catch for a mutation, and so I always get a ::pp/error
value instead of the exception being thrown.
In particular, this bit - the call (action)
is what throws (down the line is the user-provided mutation of pathom connect), and that always get caught.
value (case type
:call
(do
(assert mutate "Parse mutation attempted but no :mutate function supplied")
(let [{:keys [action]} (mutate env key params)]
(if action
(try
(action)
(catch #?(:clj Throwable :cljs :default) e
{::error e})))))
there were changes with the parallel that made things more complected around error catching, I didn't tried but I guess the fail fast thing is broken, can you please file an issue for it?
and just wondering, for what purpose are you trying to get the extension to explode? its for debug it?
actually, I use the exceptions for validation, to be caught later in a ring handler, to format as a special exception response
humm, pathom is more focused on partial failure modes, its intended to never explode entirely
you can have a request with multiple mutations and only some fails, pathom is designed to get something back to the user, so it never fails entirelyu
makes sense?
well, yes, and I don't disagree. However, the straight-forward migration path for me is to have an overall error response
I've raised https://github.com/wilkerlucio/pathom/issues/69 regarding the ::pp/fail-fast?
behaviour.
I'm only doing one mutation at a time, so the difference is mostly academic anyway. It's just easier for my client-side bits to recognize the error when it comes in that special format, rather than as a special result value in a normal mutation result.
cool, the reader part might need some more work, but I think to fail fast mutations will be an easy fix
I'll probably be able to get to it by the weekend, thanks for the report
ah, I just tough a simple thing you can do to make it explode until then
you can create a plugin around everything, look at mutation responses and trigger an error if you find any. makes sense?
On a related note, it also seems that the error-handler-plugin is not called at all for errors in mutations
so if I was hoping to format it in some special way (not necessarily rethrowing), I don't see any way of doing that other than then going some other plugin that replaces the error values with (other) error values (or throws - as you suggested).
I think mutate-async
is trapping it
you can write a custom mutate-async
, its a relative small fn
probably the fix will be changing it
this is the current impl:
(defn mutate-async
"Async mutate function to integrate connect mutations to pathom parser."
[{::keys [indexes mutate-dispatch mutation-join-globals]
:keys [query]
:or {mutation-join-globals []}
:as env} sym' input]
(if-let [{::keys [sym]} (get-in indexes [::index-mutations sym'])]
(let [env (assoc-in env [:ast :key] sym)]
{:action #(go-catch
(let [res (<?maybe (mutate-dispatch (assoc env ::source-mutation sym') input))]
(if query
(merge (select-keys res mutation-join-globals)
(<? (p/join (atom res) env)))
res)))})
(throw (ex-info "Mutation not found" {:mutation sym'}))))
humm, let me check the parallel parser
are you using parallel parser right? do your reads need async?
(def parser
(p/parser {::p/env {::p/reader [p/map-reader pc/reader2 pc/open-ident-reader p/env-placeholder-reader]
::p/placeholder-prefixes #{">"}
::p/process-error process-error
::p/fail-fast? true}
::p/mutate pc/mutate
::p/plugins [(pc/connect-plugin {::pc/register app-registry})
p/request-cache-plugin
p/trace-plugin
p/error-handler-plugin]}))
weird, the old parser should work fine with fail-fast and error handler plugin
how? that code segment I pasted in the bug report shows an unconditional try-catch around it, no?
yeah, I'm just wondering, because I was thinking of a problem somewhere else
ok, I'm gonna have to leave in a bit, sorry can't dig on this now, the regular parser and mutation parts could be interesting if you wanna investigate, by the weekend I'll have adequated time to look into
oh, just read the code you posted on the issue, that makes sense, I gotta remember why I add that there
@U8Q71JK0W just released pathom 2.2.5, this removes the try catch on the parser level, please let me know if that works properly for you, thanks for the patience for this one 🙂