This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-20
Channels
- # arachne (11)
- # aws (2)
- # beginners (33)
- # boot (167)
- # cider (71)
- # clara (2)
- # cljs-dev (28)
- # cljsrn (3)
- # clojars (1)
- # clojure (83)
- # clojure-austin (21)
- # clojure-dev (24)
- # clojure-russia (19)
- # clojure-spec (33)
- # clojure-uk (108)
- # clojurescript (114)
- # component (1)
- # core-async (1)
- # cursive (7)
- # datomic (13)
- # editors (1)
- # emacs (15)
- # hoplon (10)
- # lein-figwheel (4)
- # leiningen (3)
- # mount (2)
- # om (134)
- # om-next (4)
- # onyx (42)
- # pedestal (41)
- # quil (2)
- # re-frame (29)
- # reagent (4)
- # remote-jobs (6)
- # ring-swagger (5)
- # untangled (9)
so I’m seeing some really bizarre behavior that I can’t wrap my head around
I’ve got enter and leave interceptors set up
and I have logging in both of those, and those calls are getting hit—I see the request go through
but the response is a 404 response. I am just completely stumped as to what is going on or how to debug it at this point.
has anyone seen this?
I’m on the latest, 0.5.2, using jetty
@ddellacosta without seeing any code I can only guess that you're not assoc'ing a response to the context. Did you set up a handler for the route?
@ddeaguiar yes, I’ve got an :enter
interceptor handler set up
it dumps out a logging message, which I see, and assocs a b.s. response map to the context
but still I’m getting a 404 for some reason
I must be doing something incredibly basically stupid here but I can’t for the life of me figure out what it is
one sec
So the default not-found
interceptor checks the context for a response. If none is present then a 404
is returned
https://github.com/pedestal/pedestal/blob/master/service/src/io/pedestal/http.clj#L92
Sorry for the confusing layout and formatting; basically the top half is the interceptor code and configuration, the bottom bit is the test I’m running it within, and the fixture that starts and stops the server
I can only imagine that somehow it’s behaving as you suggest, and it’s not finding the response, but I can’t see how
what I see in my output, among other things, is the response:
12│ ?? {:request-time 6, :repeatable? false, :protocol-version {:name HTTP, :major 1, :minor 1}, :streaming? true, :chunked? false, :reason-phrase Not Found, :headers {Connection close, Date Fri, 20 Jan 2017 19:06:49 GMT, Content-Type text/plain}, :orig-content-encoding nil, :status 404, :length -1, :body Not Found, :trace-redirects []}
and, the logging message (”this shows up”)
so the not-found
interceptor uses the response?
predicate https://github.com/pedestal/pedestal/blob/master/service/src/io/pedestal/http.clj#L84
apparently that was it
thank you @ddeaguiar
I knew it was something incredibly stupid
and, thanks for the pointers to the relevant code
yeah, this cost me almost half a day, it was very frustrating
and it was an incredibly basic mistake
part of that is probably that I failed to read the necessary docs on how you should add responses to the context though
wherever those are…I’m pathological about reading docs after the fact
but yeah, suggestions welcome...
Docs can be found here: http://pedestal.io/. Requests for improvement welcome
got it—thanks for those tips, and I’ll take the time to actually read the docs now. All your help is much appreciated @ddeaguiar !
oh and yeah, as far as improving messaging I suppose it would have been super helpful if pedestal had dumped out something like, “hey dumbass, there is not a response map/your response map is missing some basic stuff…” Granted, I should have known, but I guess I was kind of assuming that pedestal would magically merge stuff in somehow. Thinking back on it I don’t know why I thought that, and the behavior I was seeing makes a ton of sense now, but a warning or something would have been great.