Add test cases for running killed jobs again

These tests expose a bug: when a job is killed, the flag that
Lorry Controller keeps (kill_job in the lorries table) to remember
that a job is to be killed is never reset, so all future attempts
at running a job for the lorry kill the job at once.

1 files changed, 23 insertions, 0 deletions

diff --git a/yarns.webapp/040-running-jobs.yarn b/yarns.webapp/040-running-jobs.yarn
index 11ec557..f637b0b 100644
--- a/yarns.webapp/040-running-jobs.yarn
+++ b/yarns.webapp/040-running-jobs.yarn
@@ -158,6 +158,16 @@ Admin will now see that the job has, indeed, been killed.
     WHEN admin makes request GET /1.0/list-running-jobs
     THEN response has running_jobs set to []
 
+Check that job can be run successfully again. In 2014, we found a bug
+where a lorry that was ever set to be killed, would never again
+successfully run.
+
+    WHEN admin makes request POST /1.0/give-me-job with host=testhost&pid=123
+    THEN response has job_id set to 2
+    AND response has path set to "upstream/foo"
+    WHEN MINION makes request POST /1.0/job-update with job_id=2&exit=no
+    THEN response has kill_job set to false
+
 Cleanup.
 
     FINALLY WEBAPP terminates
@@ -211,6 +221,19 @@ should now be telling us to kill the job.
     WHEN MINION makes request POST /1.0/job-update with job_id=1&exit=no
     THEN response has kill_job set to true
 
+Kill the job, as requested.
+
+    WHEN MINION makes request POST /1.0/job-update with job_id=1&exit=1
+
+Verify we can run the job successfully after it has been killed once
+by timeout. In 2014 we had a bug where this would not happen, because
+a lorry that had ever been killed would never run successfully again.
+
+    WHEN admin makes request POST /1.0/give-me-job with host=testhost&pid=123
+    THEN response has job_id set to 2
+    WHEN MINION makes request POST /1.0/job-update with job_id=2&exit=no
+    THEN response has kill_job set to false
+
 Cleanup.
 
     FINALLY WEBAPP terminates