runpod: make the next pod failure diagnosable from the answer
The last three pod failures were each diagnosed the same way: find the pod URL in the engine log, ask the pod by hand what it serves, work backwards. That is a diagnosis loop measured in minutes of log archaeology per attempt. Boot is now reported in PHASES, because "it took 150s" is not a diagnosis: port open after Ns (image pull + container start), serving after N more. The two have different fixes — a bigger boot_timeout_s versus a bigger load_timeout_s. The moment a pod is up, its /v1/models is logged. An empty catalogue now says so outright — "pod serves NO models — it will refuse every request" — instead of surfacing minutes later as "Model 'x' is not available. Use one of: " with nothing after the colon. And a test run's answer carries the pod diagnostics: which pods are live, their GPU, uptime, spend so far, URL, and the models each one lists. The fact that mattered in every failure so far was the catalogue, and it is now in the response rather than three commands away. Co-Authored-By:Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY
Showing
Please
register
or
sign in
to comment