I've used interceptors to model workflows, which I've found very useful when those workflows were made up of reusable chunks and had lots of asynchronous processing mixed in. Many of those workflows might trigger conditional additional steps or branches, which we'd just add on to the queue.

Martian has a :martian.interceptors/enqueue-route-specific-interceptors documented here: https://github.com/oliyh/martian#per-route-behaviour and the source code is here: https://github.com/oliyh/martian/blob/c20d3fad47709ecfc0493e2fb607d5b56ea3193d/core/src/martian/interceptors.cljc#L72-L77 @U2T2ZEVPC u were also asking me about this

btw, i would really love to see 2 separate versions of interceptors 1. one which is optimized for simplicity and hackability, without any compilation concepts and maybe even just clj compatible, to get rid the reader conditionals too 2. one which has all the more advanced features, to achieve high performance

I have also done retry mechanisms by doing a condition-system like item

e.g. where we re-queue work to be done if a request failed, as well as modify the stack so that if I put the retry item on the queue 3 times it is only there once on the exit

the biggest case is the conditional branching like mentioned above though; process and hit a decision point, then conditionally add the interceptor chain for the different paths

@U055NJ5CC As Proctor mentioned, conditionals are my most common use case. E.g., in Aleph, I conditionally place an SSL handler at the head of the interceptor pipeline if using SSL. For the new HTTP/2 code, I'm inserting an SSL protocol negotiation handler, which talks to the server and picks an HTTP version to use, and means it's literally impossible to complete the rest of the pipeline until runtime. I'm also experimenting with dynamically inserting conversion handlers to fall back to HTTP1 code when needed (like replacing an HTTP2 pipeline with HTTP1 if multipart bodies are detected).