• Stefy Lanza (nextime / spora )'s avatar
    runpod: a configured global volume must not fail every pod (v0.3.2) · 608127c8
    Stefy Lanza (nextime / spora ) authored
    Probed every API surface coderai can use for attaching a global volume, each
    with a body valid enough that the extra-key check actually runs:
    
      POST /v1/pods            key … not in input schema: 'globalNetworkVolumeId'
      podFindAndDeployOnDemand field not defined by the input type
      POST /v2/pods            additional properties 'globalVolumeId' not allowed
      templates (mounts)       every candidate key refused
    
    There is no public API for it: global volumes are console-only, as the docs
    say. Which makes `global_volume_id` a loaded gun — sending the field fails the
    create, so configuring a global volume would have stopped the install renting
    pods at all.
    
    Both create paths now recognise that specific rejection, drop the field and
    retry. The pod boots without the volume and downloads its weights: slower and
    it costs bandwidth, and far better than serving nothing. Logged once per
    process, naming the consequence and the override to set when RunPod publishes
    the field name. An unrelated failure is NOT treated this way — a capacity error
    retried with the volume stripped would bring a pod up silently wrong.
    
    Earlier probes that reported the field as "accepted" were wrong: with an
    otherwise-invalid body the validators stop before the extra-key check. Worth
    remembering next time I probe a schema.
    Co-Authored-By: 's avatarClaude Opus 5 <noreply@anthropic.com>
    608127c8
test_runpod_placement.py 15.1 KB