Be able to stop a running job

[guillaume-chervet]

Kosar ask us to be able to stop a current executing job

[guillaume-chervet]

Thank you for reaching out!

Based on our review, this appears to be already resolved. Here is a technical note that may help:

Where it lives today

Stopping a running job is already implemented behind the existing DELETE endpoint. It is symmetric: same route handles queued and running jobs.

• Route registration — src/SlimFaas/Endpoints/JobEndpoints.cs (line 47):

  DELETE /job/{functionName}/{elementId}
  

• Business logic — src/SlimFaas/Jobs/JobService.cs, DeleteJobAsync (lines 172-204):
  1. Validates visibility (Private blocks external namespaces).
  2. If elementId still matches a queued item → sends SlimDataInterpreter.DeleteFromQueueCode through jobQueue.ListCallbackAsync (removed from queue, never started).
  3. Otherwise, looks up the running/finished job in _jobs (populated by SyncJobsAsync from kubernetesService.ListJobsAsync) and calls kubernetesService.DeleteJobAsync(namespace, job.Name).
• Kubernetes side — src/SlimFaas/Kubernetes/KubernetesService.Jobs.cs, DeleteJobAsync (lines 228-259) issues:

  DELETE /apis/batch/v1/namespaces/{ns}/jobs/{jobName}?propagationPolicy=Foreground
  

  Foreground propagation makes Kubernetes delete dependent pods before removing the Job object, effectively stopping the running pod(s).
• Docs — documentation/jobs.md:
  • Section 3.3 “Deleting a Job” (lines 418-429).
  • Recap line 611: “Delete a (running, waiting, finished) job: DELETE /job/<jobName>/{id}”.

How to use it

# 1) Find the elementId (Id) of the running job
curl http://<slimfaas>/job/<functionName>

# 2) Stop it (same call whether queued, running or finished)
curl -X DELETE http://<slimfaas>/job/<functionName>/<Id>
# 200 OK   -> deletion accepted (pods terminated by Kubernetes)
# 404      -> no such Id
# 400      -> invalid function name / private visibility from external caller

Answer to Kosar

The feature is already available — use DELETE /job/{functionName}/{Id}. Because the Kubernetes call uses propagationPolicy=Foreground, the underlying pod is terminated by the kubelet (SIGTERM, then SIGKILL after terminationGracePeriodSeconds), which is what “stopping a running job” means in Kubernetes semantics. No code change is required.

Optional evolutions (only if the user wants more than what exists)

No patch is proposed since the request is already satisfied. If reviewers still want to improve UX/semantics, options are:

1. Alias endpoint POST /job/{functionName}/{elementId}/stop that internally calls the same DeleteJobAsync, purely for API clarity.
2. Grace period parameter: expose ?gracePeriodSeconds= on the DELETE endpoint and forward it in the k8s request body ({"kind":"DeleteOptions","gracePeriodSeconds":0} for immediate SIGKILL). The KubernetesService.DeleteJobAsync already has commented-out scaffolding for this on lines 240-244.
3. Distinguish “cancel queued” from “abort running” by returning a richer response payload (e.g. { "action": "dequeued" | "terminated" }) rather than just 200 OK.
4. Emit a job status event on the existing status stream (StatusStreamEndpoints) with Status = "Terminating" before the k8s delete call for better observability.

Each of the above is a small, isolated evolution and can be implemented on request. If Kosar’s real need is one of them (in particular #2 — force-kill without waiting for graceful shutdown), reclassify the issue as evolution and I can provide the patch.

We are closing this Issue for now. Please feel free to reopen it if you have further questions or the problem persists.

---

This operation was performed by an AI via GnOuGo, the cute little bear cub just waiting to be adopted: https://github.com/GnouGo/GnouGo