Fork me on GitHub
#pedestal
<
2018-08-21
>
ikitommi08:08:38

how can one test interceptor chains which have async steps?

ddeaguiar16:08:57

ah that’s my fault. You can find release notes here: https://github.com/pedestal/pedestal/releases/tag/0.5.4

👍 1
souenzzo17:08:15

Maybe a warning in #557 once it is potentially breaking

ddeaguiar18:08:01

Updated the release notes to be more explicit about this. Thanks!

ddeaguiar18:08:04

and sorry!

👍 1
ddeaguiar16:08:11

I will look to update the changelog as well

ikitommi16:08:46

@ddeaguiar thanks. But I’m poiking with the interceptor chain directly.

ikitommi16:08:02

(require '[io.pedestal.interceptor.chain :as pc])
(require '[io.pedestal.interceptor :as pi])
(require '[clojure.core.async :as a])

(-> {:kikka "kukka"}
    (pc/enqueue [(pi/interceptor {:enter identity})])
    (pc/execute))
;=> {:kikka "kukka"}

(-> {:kikka "kukka"}
    (pc/enqueue [(pi/interceptor {:enter (fn [ctx] (a/go ctx))})])
    (pc/execute))
;=> nil

ikitommi16:08:43

It works if I add a custom interceptor as first into the queue and write the value into a promise which i deref outside of the chain, but looking for a better way.

ddeaguiar17:08:26

IC, I recall having a workaround for testing requests satisfied by async interceptors before response-for handled them but it eludes me atm. I’ll try and remember

ddeaguiar17:08:43

@ikitommi here’s what I did in the past. I tend to avoid with-redefs but I found this useful. I’m sure there are better ways, though.

ddeaguiar17:08:49

it’s tightly coupled with the Pedestal’s underlying impl so that’s gross

ddeaguiar17:08:59

but hey, I was in a pinch 🙂

ikitommi17:08:09

yes it’s bad 🙂

ikitommi17:08:48

I think that could be interesting outside of tests too, as the interceptor chain can be run as standalone too.

ikitommi17:08:41

One solution would be to add a second arity to execute with a second argument which is a callback called when all done.

ikitommi17:08:38

(let [on-complete (promise)]
  (-> {:kikka "kukka"}
      (pc/enqueue [(pi/interceptor {:enter (fn [ctx] (a/go ctx))})])
      (pc/execute on-complete)
  (deref on-complete 1000 ::timeout))

ddeaguiar17:08:37

I need to go back and better understand the change made to support async response-for testing

ikitommi17:08:37

but, just wondering how it’s intended to be used, not needing this feature.

ddeaguiar17:08:38

because the solution is going to be around stubbing the async context