Details
-
Type:
Defect
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Completed
-
Affects Version/s: None
-
Fix Version/s: 0.2.0
-
Component/s: None
-
Labels:None
Description
Failures like these are happening sometimes in the test suite, mainly around stdin:
FAIL in (request-multiple-read-objects-in) (nrepl_test.clj:211)
expected: (= (quote (:ohai)) (response-values (for [resp (repl-eval session "(read)")] (do (when (-> resp :status set (contains? "need-input")) (session {:op :stdin, :stdin ":ohai :kthxbai\n"})) resp))))
actual: (not (= (:ohai) nil))
FAIL in (request-multiple-read-objects-in) (nrepl_test.clj:217)
expected: (= [" :kthxbai"] (repl-values session "(read-line)"))
actual: (not (= [" :kthxbai"] nil))
I've done a ton of debugging and thinking about this, and haven't gotten far. A few theories I had that seemed decent at the time, but ultimately haven't gotten rid of these occasional failures:
- in middleware.session/add-stdin, flush the :stdin-writer after writing to it on :stdin messages (see http://stackoverflow.com/questions/2843555/better-alternative-for-pipedreader-pipedwriter)
- in server/handler, when a message is received on the transport, farm the handling out to a future (this is half-baked & caused additional intermittent failures)
The debugging I've been doing (print statements galore) suggests that when this problem happens, the client does send back the proper :stdin, but it doesn't get picked up by the add-stdin handler in time to write to the :stdin-writer and avoid the expiring timeout.
I'm pretty much stumped at this point, unfortunately.
Pushed, will be in the next beta release. Thanks so much!