• Stefy Lanza (nextime / spora )'s avatar
    runpod: a release that cannot be honoured yet is remembered, and a pod that · a1e95f99
    Stefy Lanza (nextime / spora ) authored
    refuses our token is not an asset (v0.3.17)
    
    Both from watching a real OCR run.
    
    THE LOST INTENT. A client asked for the fleet back while a page was still being
    read. The pods correctly stayed — work is never dropped to save money — but the
    intent was then forgotten: the pool fell back to idle_timeout_s (900s there) and
    billed for a fleet nobody had asked to keep. It took a second teardown call,
    four minutes later, to actually release it. The pool now remembers: pods kept
    only because they are working are retired the moment they fall idle, the same
    "do not wait out the timeout" treatment a closed schedule window already gets.
    Asking for warm pods again cancels it.
    
    Also fixes the reply and the log, which said "floor 1" when the 1 came from work
    in flight. That reads as though the operator had asked for the pod — the opposite
    of what it meant. Demand and configuration are now reported separately
    ("needed" and "floor"), because they are two different reasons a pod survived.
    
    THE ADOPTED POD THAT 401s. After a restart the pool adopts the pod it left
    running instead of renting another, and carries that pod's bearer token across
    through the registry — when one was recorded. With none recorded it fell back to
    our own token and never checked the result, so a pod launched with a different
    one answered 401 to every request for the rest of its paid life. Seen today,
    right after a restart: "reusing the pod already running" followed by 401 on
    every OCR page. The health probe that found it proves nothing here — a coderai
    pod answers /healthz to anybody.
    
    Adoption now probes an AUTHENTICATED path with the token it would use, and a pod
    that refuses it is terminated rather than adopted: with one registry per
    deployment (0.3.15) an unrecorded key is a lost key, so that pod can never serve
    anyone, and paying for it is the only outcome worse than killing it. An
    unreachable pod is NOT treated as unauthorised — that stays with the health
    machinery, which has a budget for it.
    Co-Authored-By: 's avatarClaude Opus 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01PxYHWbCAjjjD7A1rhFKtaW
    a1e95f99
Name
Last commit
Last update
..
superpowers Loading commit data...
README.md Loading commit data...
admin-forward-auth.md Loading commit data...
cluster.md Loading commit data...
deepseek-ds4.md Loading commit data...
dtype-auto-selection.md Loading commit data...
expressive-tts.md Loading commit data...
frontend-engine-split.md Loading commit data...
gguf-process-isolation.md Loading commit data...
glm-colibri.md Loading commit data...
install-from-packages.md Loading commit data...
kimi-k3.md Loading commit data...
ktransformers.md Loading commit data...
longcat-video.md Loading commit data...
minimax-h3.md Loading commit data...
modelli-digesta-e-container.md Loading commit data...
ocr.md Loading commit data...
orchestrator-runpod-guide.md Loading commit data...
piano-inferenza-su-coderai-prod.md Loading commit data...
process-isolation-plans.md Loading commit data...
reference-projects.md Loading commit data...
remote-execution.md Loading commit data...
reverse-proxy-nginx.md Loading commit data...
runpod.md Loading commit data...
tools-as-services.md Loading commit data...
video-compose.md Loading commit data...
vllm.md Loading commit data...
zimage-lora-training.md Loading commit data...