nickva opened a new pull request #1277: In _scheduler/docs fix `crashing` state 
showing as `pending` sometimes
   Replication jobs are backed off based on the number of consecutive crashes,
   that is, we count the number of crashes in a row and then penalize jobs with 
   exponential wait based that number. After a job runs without crashing for 2
   minutes, we consider it healthy and stop going back in its history and 
   for crashes.
   Previously a job's state was set to `crashing` only if there were any
   consecutive errors. So it could have ran for 3 minutes, then user deletes the
   source database, job crashes and stops. Until it runs again the state would
   have been shown as `pending`. For internal accounting purposes that's correct
   but it is confusing for the user because the last event in its history is a
   This commit makes sure that if the last even in job's history is a crash user
   will see the jobs as `crashing` with the respective crash reason. The
   scheduling algorithm didn't change.
   Fixes #1276
   - [x] Code is written and works correctly;
   - [x] Changes are covered by tests;
   - [x] Documentation reflects the changes;

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

Reply via email to