           (message/close! client-io-handle)
           (let [outcome (deref response 10000 ::timeout)
                 end-time (System/nanoTime)]
+            (is (not= outcome ::timeout))
             (log/info prelog
                       "Verifying that state hasn't errored out after"
                       (float (utils/nanos->millis (- end-time start-time))) "milliseconds")

                      (message/parent->! srvr-io-handle bs))
          child-message-counter (atom 0)
          strm-address (atom 0)
          child-cb (fn [bs]
                     ;; This is for messages from elsewhere to the child.
                     ;; This test is all about the child spewing "lots" of data
                     ;; TODO: Honestly, need a test that really does just start off by
                     ;; sending megabytes (or gigabytes) of data as soon as the connection
                     ;; is warmed up.
                     ;; Library should be robust enough to handle that failure.
                     ;; Q: (which failure? feature?)
                     (is (not bs) "This should never get called"))
          client-initialized (message/initial-state (str "(test " test-run ") Client w/ Big Outbound")
                                                    false
                                                    {})
          client-io-handle (message/start! client-initialized parent-cb child-cb)]
      (reset! client-io-atom client-io-handle)
      (try
        (let [;; Note that this is what the child sender should be supplying
              message-body (byte-array (range msg-len))]

    (let [start-time (System/nanoTime)
          packet-count 9  ; trying to make life interesting
          ;; Add an extra quarter-K just for giggles
          msg-len (+ (* (dec packet-count) K/k-1) K/k-div4)
          response (promise)
          srvr-child-state (atom {:address 0
                                  :buffer []
                                  :count 0})
          srvr-io-atom (atom nil)
          ;; I have a circular dependency between
          ;; the client's child-cb, server-parent-cb,
          ;; and initialized.
          ;; The callbacks have access to the state
          ;; value, but not the io-loop handle.
          ;; They need that, because child->!
          ;; is going to trigger another send.
          ;; Wrapping it inside an atom is obnoxious, but
          ;; it works.
