one pod, one entry: a pool must not hold the same pod twice (v0.4.29)
Two paths append pods -- a fresh rent and an adoption -- and neither checked whether the pod was already in the pool. On a restart both fire for the same machine within the same second: [runpod] adopting pod j74fxkxr9vs3fg's bearer token [runpod] reclaim: took back a pod for 'datalab-to/surya-ocr-2' ... and the pool then held one A40 twice. Every capacity question is answered by walking self.pods, so the duplicate is not cosmetic: * the pool claimed 2 x max_inflight_per_pod = 128 slots on a card that was serving 31, reporting "2 in pool, 2 healthy, 2 at cap" with 255 pages queued -- and refusing work the pod could have taken; * max_pods is enforced against that same count, so a cap of ONE was satisfied by two entries for one pod, which is how a second real pod came to be rented beside it and billed at $1.18/hr for a configuration that asked for $0.59; * the in-flight staleness sweep added in 0.4.28 cannot help here, because both entries hold legitimate fresh timestamps. A duplicate is not a leak. Both sites now go through `_add_pod`, which is the only remaining way into the pool and refuses a pod id it already holds. The EXISTING handle is kept rather than replaced: it carries the in-flight accounting for work already dispatched to that pod, and dropping it would strand every slot it holds. What can legitimately change is refreshed onto it -- the address, since RunPod remaps ports and the pod id is the identity, not the url. A test asserts there is exactly one `self.pods.append(` in the file: the guard is worth nothing if a third path is added later that bypasses it. Co-Authored-By:Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM
Showing
Please
register
or
sign in
to comment