RunPod reclaimed an A40 mid-document today. The pool went on reporting it
healthy, so every page chose the same corpse: the in-flight count climbed, the
pod was never dropped, and nothing drained. From the client that reads as
"requests neither complete nor time out", and it is what wedged the test.

RunpodBackend has always handled this — _unreachable() drops the pod and the
request goes again. The fan-out gateway never did: it returned 502 and left the
dead pod in the pool as healthy. So a lease can now report its upstream dead,
which drops the pod, clears the cached candidate set and releases the slot; the
page is retried ONCE against whatever replaces it, and a third attempt would
just be a retry loop against a real outage.

Only connect-level failures count as dead. A read timeout is a model taking its
time over a dense page, and discarding a healthy pod for that would be an
outage of its own.

Also: the first version of that handler could not work. It used a metaclass
with __instancecheck__ so `except _DEAD_UPSTREAM` would match httpx's errors —
but `except` matches on the class hierarchy at C level and never consults
__instancecheck__, so it caught nothing. A test caught it; the check is now an
explicit isinstance() where it cannot lie.

And the registry path again: 0.3.15 keyed the fallback off XDG_CONFIG_HOME,
which the container launcher exports only into the processes IT starts. A
diagnostic script entering the container another way printed a THIRD registry
path and created a second pod TLS CA. The fallback now reads
CODERAI_CONFIG_DIR, the variable the launcher actually sets, so every process
agrees however it was started — and since pod_tls.tls_dir() derives from the
registry path, the CA follows.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PxYHWbCAjjjD7A1rhFKtaW