Ok it looks like you guys send a SIGTERM signal once the new process is live Stopping a background worker before deploy, but there seems to be some noticeable delay here, is there any way to debug when/how the old process is shutting down?
When i deploy a service to render, what exactly happens? I’m encountering a nasty bug in a service with open websocket connections and i suspect it might be because of listeners / certain code not being cleaned up on a new deploy, my question is:
is there any way to have some code executed before a new deploy is swapped in and the old service is winded down?
Rn, i have a method that listens for signal handlers to execute the shutdown, but i don’t think it’s working properly
}
// Register signal handlers for graceful shutdown
process.on("SIGINT", () => gracefulShutdown("SIGINT"));
process.on("SIGTERM", () => gracefulShutdown("SIGTERM"));
One thing to look out for is if you’re starting your service with npm ... (or some other process manager/library), it will intercept these signals. Try starting it directly with node ... and let me know if that helps.
I just tried this and it unfortunately, it still did not solve my problem, is it possible to get in touch with someone from support for some more detailed debugging?
It would mean not using npm or npx, and just use something like node server.js (but replace server.js with whatever file you use to start your web service.
If you still need additional assistance, you can always open a support ticket using the Help link at the top of the dashboard.
Got it, and just to clarify, in the doc you linked above How Deploys Work | Render Docs it looks like even after deploying the new service, both the old and new services stay running for 60 seconds before a SIGTERM command is sent to the old service. This seems like this could be the root of the issue because, the service I’m running is an indexer that processes web socket events in real-time, so anything in that window will always be double processed? Is there some workaround? Is there a way to specify the old service be killed as soon as the new service is running instead of after this 60 seconds?
Requests shouldn’t go to the both old and new instances. In step 3 the docs mention
Render also updates its networking configuration so that your newinstance begins receiving all incoming traffic
The old instance stays around to finish processing any long running requests/jobs. I’d suggest adding some logging to confirm you’re able to receive the SIGTERM signals as expected.