Fork me on GitHub

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


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


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


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


totally agree with that


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.


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


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


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


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


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


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


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


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


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


I’d read that


(love your newsletter, btw)


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