Fork me on GitHub
#core-async
<
2017-03-22
>
bbrinck21:03:57

Perhaps this is a bad idea, but I think it would be useful to detect CLJS tests that creates core.async work that is “stuck”. This was my attempt based on help I got in this channel back on March 17, but I can’t get it to work in the case shown in this gist https://gist.github.com/bhb/4bd1897b0f5c761ed9782dae038819dd

bbrinck21:03:00

I realize this all depends on internals that could change without warning, but since this is just to ensure our tests are sane, i’m willing to endure any upgrade pain and adjust our helpers accordingly if core.async internals chanage

hiredman21:03:28

so this won't help get that working, but what I like to do with "blocking" operations in tests is always have a timeout with a failing case. I do that with core.async in clojure, but I am not sure how that would apply to cljs.test

hiredman21:03:07

tests that hang when something fails don't make me happy

bbrinck21:03:36

totally agree with that

bbrinck21:03:24

the problem we’re having is two fold - first, if we mess up our tests, we miss an assertion that would catch something. you can work around this by carefully writing tests that fail if a block isn’t run, but an automated check would help us catch mistakes. secondly, we’re having issues where running tests in doo for long periods of time will slow down over a series of runs and eventually lock up, so we have to restart our test process.

bbrinck21:03:33

i’m not sure what’s causing that (i’ve captured profiles in chrome, but they haven’t revealed anything so far) but one thing I’d like to eliminate is the possibility that tests are creating a bunch of blocked core.async work over time and somehow preventing new, legitimate core.async work from running

hiredman21:03:38

from my understanding of core.async internals (based on the clojure side of things, so with a huge grain of salt) a blocking task would only stick around if the channel it is blocked on also sticks around

bbrinck21:03:05

Hm, that could be true. Maybe there really isn’t any blocking work in this case.

danielcompton21:03:35

but that code is pretty convoluted for what you're trying to do

bbrinck21:03:15

I know that blocking on timeout channels (which may be a totally different case) is something that can stick around between tests. If you take! on a timeout channel, that callback could be fired during a subsequent test

bbrinck21:03:46

but timeouts have their own state, at least from my reading of the core.async code, so maybe blocking on a non-timeout channel really does clean itself up

danielcompton21:03:39

I should write up a blog post about how CLJS treats async tests

danielcompton21:03:50

it took me a little while to figure out what was actually going on

danielcompton21:03:18

and if I don't write it up, I'll need to relearn it in a year 🙂

bbrinck21:03:52

I’d read that

bbrinck21:03:58

(love your newsletter, btw)

noisesmith23:03:41

is there a good reference for async versions of various IO in clojure? I have found aleph for tcp / http, and :callback as an optional arg in zookeeper-clj, but am still looking for good async access to postgres and mongo