Locally testing a worker where the consuming code relies on the job ID
Hi there,
I'm working on a codebase where a RunPod worker is used to execute a workload that takes ~40 seconds, and then the result is sent to the webhook with the job ID and state.
I have been attempting to test this worker locally for faster iteration, but I've been discovering that RunPod's development workers seem to have discrepancies with the production workers, and that these aren't really documented.
I found out that:
- https://discord.com/channels/912829806415085598/1275706978856996904/1298641999704100946:
/run is not supported
- https://discord.com/channels/912829806415085598/1294445586753519717/1299515602511335435: /status is not supported
- https://docs.runpod.io/serverless/references/operations: /runsync doesn't return a job ID, even in the webhook
My consuming code is quite reliant on the job ID and state returned in the webhook, so naively switching over to /runsync doesn't work.
Is there anything I can do to run a job using my local worker and get the job ID and state back in the webhook? I don't care if it's synchronous, but I need something that responds in a similar format to the production /run endpoint.1 Reply
Digging into the FastAPI code, it doesn't look like this is possible - the webhook will never return the job ID for either
/runsync or /status for the webhook:
- https://github.com/runpod/runpod-python/blob/2c62255c5638e2aef3176317c20365daef9b73d1/runpod/serverless/modules/rp_fastapi.py#L333-L343
- https://github.com/runpod/runpod-python/blob/2c62255c5638e2aef3176317c20365daef9b73d1/runpod/serverless/modules/rp_fastapi.py#L410-L420
I might have to monkeypatch this at runtime >_>