nope, still not working

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

Is it a :leave or an :enter concern?

:leave

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.

@orestis https://gist.github.com/deadghost/92915712227882f7bfe7d3af42988951

pretty much 1:1 with pedestal guide example

works in route interceptor stack

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

https://gist.github.com/deadghost/bee98e65d29bf242c7428d880680470d default stack snippet

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?

I'll try your enter suggestion

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

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

defaults

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

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

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

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.

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

https://gist.github.com/deadghost/cbf49f2faa50ba56e8a43cda3326538b

I must be doing something fundamentally wrong

because with just that inspect interceptor and the router interceptor`

nothing gets printed

inspect works as a route interceptor as well

but not as a default interceptor

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

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.

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?

@orestis found the problem

it's a really stupid mistake

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

what a waste of two days

We’ve all been there 🙂

😅 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

@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

@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.

this is the relevant code https://github.com/pedestal/pedestal/blob/0.5.4/service/src/io/pedestal/http/impl/servlet_interceptor.clj#L232-L234

@mavbozo huh thanks for the tip

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

yeah my :headers can't be nil

ok finally got pedestal reasonably set up

I can finally close like 20 pedestal tabs

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

@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

@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.

@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.

@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

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

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