Hey, can you change the restart policy and number of retries in your service's settings.

I did - it's set to Always. But it still doesn't restart on crash.I wonder if it's a zero exit code. It's crashing for a heap exception (which I think is a non-zero), but I can't think of any other reason it won't auto-reboot.

Hey, does your service actually "crash" or is it just in a state where it is technically still running but no longer responsive.

It's definitely crashed. We can an email from Railway indicating our service has crashed, and it's red in the dashboard with the "Crashed" badge with a "Restart" button.

Thank you for confirming this. Can this behavior be reproduced consistently? Also, may I ask the amount of retries you specified and the amount of crash emails you get each time this happens?

We receive one email, and yes it happens consistently - at least a few times a week. If we choke out the RAM limit, we can probably get it to happen a few times a day.Here's our restart policy. Not sure where to find the amount of retries, but happy to share if you can guide me!

Since it is configured to always restart, there isn't a field to specify the amount of retries. Is the crash related to the fact that your service exceeds the max amount of memory it can scale up to (OOM)?

Yes almost definitely. It’s usually a heap exception in NodeJS that kills it.We clearly have a small memory leak and we need to resolve that.But in the meantime, I’d have hoped when we do crash, it’d come back to life.

Hey, I tried to replicate the OOM behavior with a service and run into a crash loop that eventually ended after some time (retry policy was set to Always). I have also talked with the team and the crash loop behavior will be improved with the next runtime. For now or in general, the best solution is preventing your application from crashing indefinitely by fixing the memory leak.

Hey,What does that mean? What is the next runtime? Is there a rough ETA on that?Does that mean in the meantime auto-restarting just doesn't function for OOM deaths?Is this considered a bug internally or by-design?Obviously yes, resolving memory leaks is top priority. Working on that for sure.But as every developer knows, weeding out memory leaks isn't always straightforward.If a service errors out (rogue code, memory leak, whatever; anything that saps resources dry), we can't rely on the auto-restart?To be honest, this feels like a larger issue than its being made out to be.Currently, this leaves someone babysitting the service at all hours of the day.

Hey,What does that mean? What is the next runtime? Is there a rough ETA on that?Does that mean in the meantime auto-restarting just doesn't function for OOM deaths?Is this considered a bug internally or by-design?Obviously yes, resolving memory leaks is top priority. Working on that for sure.But as every developer knows, weeding out memory leaks isn't always straightforward.If a service errors out (rogue code, memory leak, whatever; anything that saps resources dry), we can't rely on the auto-restart?To be honest, this feels like a larger issue than its being made out to be.Currently, this leaves someone babysitting the service at all hours of the day.

Hey, I have been told by the team, that your service is indeed restarting, just that it is like the same exact situation as I have reproduced, which is an infinite restarting loop that got terminated, as it has been restarted a lot of times.

Interesting - but then the "Restart" button on a [Crashed] container works immediately and every time.Is there a difference between the auto-restart vs the "Restart" button that we should be accounting for maybe?