summaryrefslogtreecommitdiff
path: root/yarns.webapp
diff options
context:
space:
mode:
Diffstat (limited to 'yarns.webapp')
-rw-r--r--yarns.webapp/040-running-jobs.yarn23
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