   ;; Q: Is this a background-thread hidden sort of thing?
   ;; Maybe CIDER just isn't clever enough to spot it?
 
-  (is (not (= success ::timed-out)))
-  (is (not (= success ::drained)))
+  (is (not (= released-buffer ::timed-out)))
+  (is (not (= released-buffer ::drained)))
+  ;; This is just the tip of the iceberg showing
+  ;; why this approach was a terrible idea.
+  (is (= released-buffer released-buffer))
   ;; TODO: Make this more interesting.
   ;; Verify what we really got back
   ;; Send back a second block of data,

    ;; Q: What's up with that?
    (let [succeeded (deref wrote 3000 ::check-timeout)]
      (log/info (str "Client-child send result to " write-notifier " => "  succeeded " @ " (System/nanoTime)))
      ;; N.B. for real implementations: use a PooledByteBufAllocator
      ;; Instead of mucking around with this release-notifier nonsense
      ;; That should work around my current bug, though it's ignoring a
      ;; fundamental design flaw.
      (deferred/chain release-notifier (partial notified-about-release write-notifier release-notifier read-notifier))

  ;; 1. Start by writing 0 bytes
  ;; 2. Write, say, 480 bytes, send notification, then 320 more
  (let [write-notifier (strm/stream)
        ;; Real implementations really must use a
        ;; PooledByteBufAllocator.
        ;; Of course, that needs to get set up at the
        ;; outer pipeline level.
        ;; Client shouldn't care: when it's done
        ;; reading a buffer, it should call .release
        ;; and be done with it.
        ;; TODO: Make that happen (just not tonight)
        buffer (Unpooled/buffer 2048)
        release-notifier (strm/stream)
        read-notifier (strm/stream)
