summaryrefslogtreecommitdiff
path: root/yarns.webapp
diff options
context:
space:
mode:
Diffstat (limited to 'yarns.webapp')
-rw-r--r--yarns.webapp/040-running-jobs.yarn32
1 files changed, 27 insertions, 5 deletions
diff --git a/yarns.webapp/040-running-jobs.yarn b/yarns.webapp/040-running-jobs.yarn
index 11ec557..879d9fa 100644
--- a/yarns.webapp/040-running-jobs.yarn
+++ b/yarns.webapp/040-running-jobs.yarn
@@ -58,7 +58,7 @@ Requesting another job should now again return null.
Inform WEBAPP the job is finished.
WHEN MINION makes request POST /1.0/job-update with job_id=1&exit=0
- THEN response has kill_job set to false
+ THEN response has kill set to false
WHEN admin makes request GET /1.0/lorry/upstream/foo
THEN response has running_job set to null
WHEN admin makes request GET /1.0/list-running-jobs
@@ -140,14 +140,13 @@ Admin will now ask WEBAPP to kill the job. This changes sets a field
in the STATEDB only.
WHEN admin makes request POST /1.0/stop-job with job_id=1
- AND admin makes request GET /1.0/lorry/upstream/foo
- THEN response has kill_job set to true
+ THEN response has kill set to true
Now, when MINION updates the job, WEBAPP will tell it to kill it.
MINION will do so, and then update the job again.
WHEN MINION makes request POST /1.0/job-update with job_id=1&exit=no
- THEN response has kill_job set to true
+ THEN response has kill set to true
WHEN MINION makes request POST /1.0/job-update with job_id=1&exit=1
Admin will now see that the job has, indeed, been killed.
@@ -158,6 +157,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 set to false
+
Cleanup.
FINALLY WEBAPP terminates
@@ -209,7 +218,20 @@ Pretend to be a MINION that reports an update on the job. WEBAPP
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
+ THEN response has kill 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 set to false
Cleanup.