#Does /runsync have a timeout?

50 messages · Page 1 of 1 (latest)

muted linden
#

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!

rigid wasp
#

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

muted linden
#

So i could even have an endpoint with /runsync running for 1-3minutes, as long as my specified timeout is longer than that?

rigid wasp
#

Yess

#

Keep in mind your request still going to return your request ID after a minute if it's not returned

muted linden
#

so its going to switch into what /run would be doing?

glossy zenith
#

@rigid wasp 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

rigid wasp
#

Haha yes

rigid wasp
#

So you have to either poll /status

#

Or use web hook setting

rigid wasp
glossy zenith
#

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

rigid wasp
#

hmm

#

no it doesn't "transforms"

#

thats how it is

glossy zenith
#

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

rigid wasp
#

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

muted linden
#

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

glossy zenith
#

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?

rigid wasp
#

please write it on #1185337232517759028 if you want to suggest any edit, or yeah posting it on a ticket works

rigid wasp
glossy zenith
#

I dont want to "suggest" I want the company to answer for a miss direction

#

We'll try the email route then

#

thanks

rigid wasp
#

Im sorry yeah i know runpod docs isn't that complete

rigid wasp
#

your welcome!

muted linden
#

you've been helpful anyways to solve our doubts, at least now we know what to expect 🫠
thanks!

rigid wasp
#

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

muted linden
#

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.

rigid wasp
#

Ah yea 60s, from your request

muted linden
#

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 :$