๐จ Runbook: RunPod API Errors
:::danger Not in use since 2026-08-16 RunPod is disabled. Lambda is the only GPU provider. Nothing dispatches to RunPod, so these symptoms should not occur โ if you are seeing them, something has re-enabled the provider.
RunPod was a paid fallback that sat at 402 Insufficient Balance, which turned
a dead Lambda worker into GPU_JOB_FAILED with the user's video intact in
Storage rather than a slower run. The adapter is still in the tree; re-enabling
means funding the account and naming runpod in GPU_PROVIDER_POLICY.enabled.
Keep this runbook for that day.
:::
:::warning Audit scope
RunPod configuration and provider behavior belong to the excluded GPU backend
and were not re-verified in the 2026-07-23 non-GPU audit. The older
last_verified date is intentional. Confirm current provider configuration and
API behavior before following commands on this page.
:::
- Severity: ๐ด Critical โ no videos can be processed
- Time to mitigate: 5-10 min (rollback) / 30-60 min (fix)
Symptomโ
processVideoOnUpload logs show one or more of:
RunPod API error: 500or502RunPod API error: 401 - Unauthorizedfetch failedโ network error- Jobs get created but immediately fail, or stall with RunPod returning
IN_QUEUEforever
Impactโ
๐ด All new uploads fail to process. User-visible: spinner โ timeout โ "something went wrong". No mitigation without a working RunPod endpoint.
Diagnosisโ
Step 1 โ Verify the RunPod endpoint is aliveโ
- Open runpod.io/console/serverless
- Select the AceSense endpoint
- Check the health banner and recent requests
If the endpoint shows "No workers available" or "Endpoint disabled" โ config issue (Step 3). If the endpoint shows recent failed requests โ image issue (Step 4).
Step 2 โ Verify secretsโ
firebase functions:secrets:access RUNPOD_ENDPOINT_ID --project acesense-prod
firebase functions:secrets:access RUNPOD_API_KEY --project acesense-prod
Both must return values. If either is empty or stale (rotated on RunPod side but not updated in Firebase), the dispatch will fail with 401.
Step 3 โ Check endpoint configโ
- GPU type: should be NVIDIA RTX 4090
- Docker image: should match the latest known-good tag (e.g.
akshaysarode/acesense:v46) - Max workers: 10
- Min workers: 0
- Idle timeout: 60s
Step 4 โ Check a failing worker's logsโ
On the RunPod Requests tab, click the latest failed job. Common errors:
ImportError/ModuleNotFoundErrorโ image built with wrong Python depsCUDA out of memoryโ video too large, or batch size too highTimeoutโ job exceeded 10-min execution limit
Mitigation (make the pain stop)โ
Option A โ Rollback to last known good imageโ
- In the RunPod console, edit the endpoint
- Change the Docker image tag to the last known-good version (e.g.
vN-1) - Save โ workers pick up on next cold start (new jobs within ~60s)
Option B โ Rotate the API key if compromisedโ
# Generate a new key in the RunPod console first
firebase functions:secrets:set RUNPOD_API_KEY --project acesense-prod
# Paste new key when prompted
firebase deploy --only functions --project acesense-prod
Option C โ Pause uploadsโ
If neither above helps, stop new uploads to prevent user frustration:
// Deploy a temporary Storage rule
match /videos/{path=**} { allow write: if false; }
Then revert once resolved. Post to #acesense-dev.
Resolutionโ
- If rollback fixed it โ diagnose why the new image broke (likely a PR merged to gpu-backend). Fix + rebuild + push new tag + update endpoint.
- If secrets were wrong โ update via
firebase functions:secrets:setand redeploy. - If infra issue on RunPod's side โ check status.runpod.io and wait it out. No user-side fix.
Preventionโ
- Run
pytest tests/before building a new Docker image - Tag Docker images with commit SHA, not just version, so rollback is unambiguous
- Add a smoke test: after Docker push, fire a RunPod request with
input_videos/sample.mp4and verify the handler returns success - Wire up a RunPod health-check function that runs hourly and alerts on failure