Does /runsync have a timeout?
Hello there. I'm trying to figure out if the syncronous endpoints do have a default timeout.
The doc states that they're "ideal for short-lived tasks", but it only talks about recommendation rather than actual requirements.
Thanks!
27 Replies
Not really, you define it on the edit endpoint or per request for timeouts
Runsync job expires faster after it's return
Compared to run
And the payload has higher limits for runsync
So i could even have an endpoint with
/runsync running for 1-3minutes, as long as my specified timeout is longer than that?Yess
Keep in mind your request still going to return your request ID after a minute if it's not returned
so its going to switch into what /run would be doing?
@nerdylive sorry is there a reference to this in the documentation? I cannot find this anywhere
I find it very difficult to believe that Runpod is doing something like this, is super antipattern
If I call a sync API I should get an error OR a sync response
Haha yes
It acts like run, return the ID, but job result still times out after 30 or 60 secs after the job done
So you have to either poll /status
Or use web hook setting
Try to search
Hmm what do you mean
I dont find anything about this transformation of a /runsync to /run in the docs, even the AI does not find anything
Another query, I'm almost 100% sure there is no reference to this behaviour in the docs
hmm
no it doesn't "transforms"
Endpoint operations | RunPod Documentation
RunPod's Endpoints enable job submission and output retrieval, using a constructed URL starting with https://api.runpod.ai/v2/{endpoint_id}/{operation}. Operations include job submission, synchronous execution, job status checking, and more.
Since /runsync waits for a respond, if until 60 secs it doesn't return yet ( still processing ) it will return https://docs.runpod.io/serverless/references/job-states in progress job state, with an job id
Job states | RunPod Documentation
Understand the various states of a job in RunPod's Handler Functions, including IN_QUEUE, IN_PROGRESS, COMPLETED, FAILED, CANCELLED, and TIMED_OUT, to effectively manage job flow and troubleshoot issues.
thats how it is
I'm sorry but that is not what is stated there
/run will give us a job ID
/runsync will give us the result of the worker
Yes, but try it out
if you don't believe me
try making a job that runs longer than 1 minute
and if it hasn't returned any job result, it'll return in_progress
i think we believe what you're saying, but the point is that we should revise the documentation
because it doesn't state the same
Okay yes
is not that I dont beleive you, is that we are paying for a service that is not doing what is stated in the docs
can you raise this ticket to second level?
please write it on #🧐｜feedback if you want to suggest any edit, or yeah posting it on a ticket works
For contacting support staffs directly try to create a ticket from the website's contact
I dont want to "suggest" I want the company to answer for a miss direction
We'll try the email route then
thanks
Im sorry yeah i know runpod docs isn't that complete
sure that works too
your welcome!
you've been helpful anyways to solve our doubts, at least now we know what to expect 🫠
thanks!
yeah your welcome too 🙂
But i'd suggest using /run if you want to use it for production, got bigger rate limits, longer time for your job results to expire -> meaning more flexibility to collect it
We’ll surely look into using /run + webhooks as the /runsync behavior is completely unpredictable.
After some tests from our end, we believe that the “behavior” switch happens upon 60s of waiting time (worker not ready, queues…) rather than execution time.
Ah yea 60s, from your request
Not really, we managed to get responses after 70s as we had about 35s of waiting time and 35s of execution time. It’s definitely a bit confusing :$
oh wow