Fork me on GitHub
#pedestal
<
2018-09-25
>
deadghost08:09:45

nope, still not working

deadghost08:09:53

my coerce-body just seems to get skipped over no matter where I put it in the default interceptors stack

orestis08:09:32

Is it a :leave or an :enter concern?

orestis08:09:43

If you paste a relevant snippet I might be able to help more — it seems like it should work if it is at the top of the stack, after all the default interceptors. I’ve done this in my own experiments with minimal fuss.

deadghost08:09:04

pretty much 1:1 with pedestal guide example

deadghost08:09:18

works in route interceptor stack

deadghost08:09:28

doesn't work when I put it into the default stack

orestis08:09:20

Hm, I missed the default stack issue. All I can suggest is, try putting an enter interceptor there as well that prints the interceptor queue? Or perhaps some other interceptor there is calling terminate early so your interceptor is never running?

deadghost08:09:10

I'll try your enter suggestion

orestis08:09:12

I’m not 100% sure what’s going on if you call terminate on the way out.

orestis08:09:42

Are proute and mw your own dependencies or pedestal’s defaults?

deadghost08:09:08

was tired of conj, cons, whatever to pedestal's defaults

deadghost08:09:24

easier to see the full stack if I just put it all in a vector

deadghost08:09:37

and no it doesn't work any better when I call the defaults fn

orestis08:09:14

Would ::http/routes have any effect on the router there? I vaguely remember that all this configuration is only needed to create the default interceptor stack, otherwise you’re on your own.

orestis08:09:16

At this point I’d break out the debugger, if you can.

deadghost10:09:30

I must be doing something fundamentally wrong

deadghost10:09:06

because with just that inspect interceptor and the router interceptor`

deadghost10:09:16

nothing gets printed

deadghost10:09:31

inspect works as a route interceptor as well

deadghost10:09:37

but not as a default interceptor

orestis11:09:42

I suspect that the issue is the way you create your default interceptor/servlet stack.

orestis11:09:56

Looking at https://github.com/pedestal/pedestal/blob/master/service/src/io/pedestal/http.clj#L254, it seems that some of those interceptors are wrapped with interceptor, some are passed extra arguments, etc. It’s not clear in your server snippet what are you passing in.

orestis11:09:12

I’m not an expert in pedestal and this part of the code seems quite hairy to me, so I can’t help any further there — other than to suggest that it might make sense to adopt the official way to do things?

deadghost11:09:15

@orestis found the problem

deadghost11:09:23

it's a really stupid mistake

deadghost11:09:01

I've been editing the production interceptors instead of the dev

deadghost11:09:39

what a waste of two days

orestis11:09:27

We’ve all been there 🙂

mavbozo12:09:06

😅 my recent stupid mistake was I wasn't aware that servlet-interceptor terminates chain execution when it encounters valid ring-response in context's :response, the executors removes the rest of the :queue from the context and starts processing :leave stages. I should have properly read servlet-interceptor reference here http://pedestal.io/reference/servlet-interceptor

deadghost12:09:06

@mavbozo my current issue is I have an authentication interceptor that does attach a non-nil :response but it doesn't appear to short-circuit

mavbozo12:09:53

@deadghost woops.. I made mistake above. by reading the servlet-interceptor codes I found that servlet-interceptor terminates when it encounters valid ring-response in the context's :response. I've edited my message above.

deadghost13:09:32

@mavbozo huh thanks for the tip

deadghost13:09:50

apparently my response doesn't pass ring-response/response?

deadghost13:09:49

yeah my :headers can't be nil

deadghost13:09:45

ok finally got pedestal reasonably set up

deadghost13:09:54

I can finally close like 20 pedestal tabs

stathissideris14:09:28

is there any compelling reason to keep body params named after their content type? I’m tempted to add an interceptor that will just rename everything to :body-params so that I can have an API that will serve both edn and json requests through the same code

ikitommi14:09:18

@stathissideris if you are interested in 3rd party addons, there is a pedestal-compatible interceptor doing just that in Muuntaja library, muuntaja.interceptor.format-interceptor

stathissideris15:09:36

Thanks, I’m interested in 3rd party party interceptors, even if it’s just as an example!

ddeaguiar14:09:16

@stathissideris the Pedestal philosophy around this sort of thing is: If something is separate, keep it separate. If something can be customized via an interceptor, keep the base code as basic as possible. So adding an interceptor which does what you’ve stated is perfectly acceptable. There has been some back-and-forth internally as to whether such helpers should be included in Pedestal core. As of now they won’t.

dadair15:09:53

@stathissideris I had the same problem and for a while had my own helper interceptors to consolidate it. Ive since moved to muuntaja as @ikitommi referenced and Ive been very happy with it.

stathissideris15:09:03

@ddeaguiar thanks, that makes sense, it’s trivial to add a basic interceptor to achieve it anyway. I like the design decision. I just wanted to make sure I wasn’t missing something

deadghost20:09:47

yeah I was also wondering about the content type body params thing

deadghost20:09:23

third party interceptors haven't been easy for me to discover