Ambiguity of handling runsync cancel from python handler side
Hi. What's the best way I can handle "cancel" signal in serverless server/handler side? Is default cancel logic just stopping the container all together?
3 Replies
We maintain your job queue for you, so you can just POST /:endpointId/cancel/:jobId and not worry about it :)
what if I have one instance and I worry about cold start on the next request right after previous one was cancelled
I believe the worker boot does not get affected by :cancel, it still boots up and checks the queue, sees no job to acquire and stays idle. Thats my thought