Thread-local safety of with-redefs in parallel Clojure integration tests

Answer

with-redefs rebinds a Var using Clojure's binding mechanism, which stores the new value in a thread‑local slot. The rebinding is visible only on the thread that evaluates the with-redefs form and any thread that receives the current binding through explicit conveyance (e.g. bound-fn or with-bindings*). It does not automatically propagate to threads started by future, pmap, a Java ExecutorService, or core.async/go blocks.

Confirmed facts

• with-redefs is implemented with binding, giving each thread its own Var value.
• Parallel test runners (kaocha :parallel, clojure.test :parallel) run each test namespace on its own JVM thread, so rebindings in one test do not leak into another.
• Spawned threads that do not receive conveyed bindings see the original (root) Var value.
• Explicit conveyance mechanisms (bound-fn, with-bindings*, or wrapping work in the thread macro) copy the current dynamic bindings to the new thread.
• Using a mutable indirection (a dynamic Var holding an atom or reference) lets all threads see the same mock without needing conveyance.

Likely explanation (common pitfall)

• The system under test launches background work via future, ExecutorService.submit, or core.async/go. Because those threads lack the conveyed binding, they call the original implementation, causing intermittent test failures.
• Assuming with-redefs provides a global mock leads to nondeterministic failures when parallelism or async is involved.

Steps for this case

1. Identify where the code under test creates asynchronous work (future, pmap, ExecutorService, core.async/go).
2. If you can wrap that work, replace the raw spawn with a conveyed version:

(with-redefs [client-fn (fn [] :mock)]
  @(future ((bound-fn client-fn))))

3. Alternatively, introduce a mutable indirection that all threads read:

(def ^:dynamic *http-client* real-client)

;; test
(with-redefs [*http-client* (atom :mock-client)]
  (run-system))

;; production code
(deref *http-client*)

4. For core.async/go blocks, move blocking parts to core.async/thread or wrap the go‑block body with bound-fn:

(go (bound-fn (do-work)))

5. If the codebase is large, consider a dependency‑injection framework (Component, Integrant, Mount) to assemble a test system with mocks, eliminating the need for with-redefs altogether.

Diagnostic question

Does the component under test start asynchronous tasks via future, ExecutorService, or core.async/go? Knowing the exact mechanism determines whether bound-fn conveyance or a mutable indirection is the simpler fix.