mirror of
https://github.com/meteor/meteor.git
synced 2026-05-02 03:01:46 -04:00
e50b182772
Bump up the crashCount reset delay from 3 seconds to 8 seconds. If the delay is smaller than app start-up time, then an app that crashes at start-up will be treated as an app that crashed while running and will be automatically restarted, and this will lead to an infinite loop of restarting. Making the delay longer just increases the time right after app start where a crash counts towards the max of three restarts in a row. For example, if we upped the delay to 60 seconds, then an app that crashed in its first minute would restart but gain a crashCount of 1, and if there were two more crashes within the first minute of running (without another crash *not* within the first minute to reset the counter), the app would fail to automatically restart. This whole mechanism is a little janky and was written way way back. The number 3 was previously 2, but app start-up got a little bit slower. Hopefully the number 8 will last us until this code is replaced.
Runners
The Meteor tool process would run multiple big "parts" that should be managed: started, stopped, restarted, monitored for crashes, etc.
The interface that Meteor tool uses is called a "runner".
Some of the runners run sub-processes. The main runner is called run-all, it
has sub-runners such as run-app, run-mongo and run-proxy. Other runners
are used for different CLI commands.
Run Log
The output of the runners (compilation errors, state change, etc), should be reported through the Run Log. Run Log is also something that users see in their browsers, when their app breaks.