Fork me on GitHub

Hi, I have a question regarding a core.async test. I have a potentially infinite lazy-seq that is being produced to a chan (named request-chan) via onto-chan! . I’m performing some parallel operation and producing results to another chan named response-chan. However, I only want this operation to run for a certain period of time, so I have another go block where I call close! on request-chan after a timeout chan produces a value. I have a test written that calls (a/into [] response-chan) before setting up the pipeline and timeout. My test then blocks until the result from the aforementioned a/into is available. My test then asserts that the result is non-empty. My test specifies a timeout value of 100ms. Locally, this test always passes. However, on our CI server where multiple tests from multiple projects are competing for CPU resources, this test can become resource starved. The timeout fires and closes the request-chan before onto-chan! can produce anything from the lazy-seq onto the chan. Has anyone run into similar issues before? Any suggestions on how we should design our tests around this?


Why don't you just take x number of things from response chan and then close


You'll kind of have the problem that if your thing doesn't work your test never finishes though, but you could put a much bigger timeout on it then. So it could end either in 5min or if something was taken.


  (let [res (a/alt! response-chan :success
(a/timeout 5000) :failed)]
    (a/close! request-chan)
    (is (= res :success)))


That makes sense. I’ll go that route. Thank you!