search

pvolok / mprocs

Run multiple commands in parallel
MIT License
1.47k stars 49 forks source link

autorestart - more forgiving restart logic #144

Open jjanyan opened 2 months ago

jjanyan commented 2 months ago

Currently if autorestart is set:

  1. app runs
  2. you have an error/typo in your code and hit save
  3. the app dies
  4. mprocs restarts
  5. it likely dies again (depending on where your mistake was)
  6. you now have to manually start the application once you've fixed your mistake

Can we consider a more forgiving workflow for this?

An option is a new config. Something like "unlimited-restart", default false. If set to true, it would restart continually.

Is there a concern for getting into a tight restart loop? I assume that is why this 1 second limit was put into place.

For my use case, I'm fine with accepting the tight restart loop. It matches behavior for similar tools.

If we're trying to exceed those tools, another optional "max-backoff" could be useful. 1ms -> 2ms -> 4... $maxBackoff. If you're worried about a tight loop you can set that value to something like 5 minutes.

Maybe another approach?

pvolok commented 2 months ago

The autorestart option definitely needs a lot of work. I would like to make mprocs also suitable for running apps in production. For that we need to understand common practicies that people are using.

autorestart: true should give you some convenient starting point for dev workflow. And then autorestart should accept an object for fine tuning this behavior.

Current 1 second limit is very arbitrary. I think it's better to have a growing interval between restarts, but current architecture doesn't allow this kind of behavior to be easily implemented.

I will collect examples in this issue of how other tools (kubernetes, systemd, pm2, etc) deal with this, so that we can have it as flexible as possible but also provide a good default.