Describe the task you're waiting for as text, and let an LLM pick the number of seconds for each request. More expensive the better model you clearly need for this. There, your AI pitch.
Retries won’t work in that case. Would be better to have two endpoints: get the time in x seconds and wait until time passed. That way retrying the wait endpoint will work fine and if time hasn’t elapsed it can just curl itself with the same arguments.
If you have curl (but not sleep) sure, but if not maybe you can use bash's wacky /dev/tcp. The microservice could listen on ports 1 through 64k to let you specify how many seconds to sleep.
Maybe a more serious fix is something like "read -t $N". If you think stdin might not be usable (like maybe it will close prematurely) this option won't work, but maybe you can open an anonymous FD and read from it instead.
I see. I did not realize SECONDS was a built in bash variable.
It is still not a proper fix. It is still busy-looping 100% CPU.
Given that Github Actions is quite popular, probably wasting large amount of energy.
But probably good at generating billable Actions minutes.
One can only hope that not many people use sleeps to handle their CI race conditions, as that itself is also not a proper fix.
Clearly the job for a microservice. Accept number of seconds to wait as url, return content after that many seconds. Then just use curl in runner.
Brb founding a SaaS startup. I’ll call it cloudsleep dot io of course. After our Series B I’ll buy the .com.
Only task to do before lining up investors is how can I weave AI into our product?
Describe the task you're waiting for as text, and let an LLM pick the number of seconds for each request. More expensive the better model you clearly need for this. There, your AI pitch.
Excellent, welcome aboard, Chief Product Officer!
Retries won’t work in that case. Would be better to have two endpoints: get the time in x seconds and wait until time passed. That way retrying the wait endpoint will work fine and if time hasn’t elapsed it can just curl itself with the same arguments.
If you have curl (but not sleep) sure, but if not maybe you can use bash's wacky /dev/tcp. The microservice could listen on ports 1 through 64k to let you specify how many seconds to sleep.
Yeah, definitely not a proper fix.
Maybe a more serious fix is something like "read -t $N". If you think stdin might not be usable (like maybe it will close prematurely) this option won't work, but maybe you can open an anonymous FD and read from it instead.
Me neither. I am over 40 and did not know this. Feels good to learn something today, in an unexpected place!