This thread contains a patchset. You're looking at the original emails, but you may wish to use the patch review UI. Review patch

[PATCH builds.sr.ht] api: allow cancelling of orphaned jobs

Message ID
DKIM signature
Download raw message
Patch: +6 -1
I think the code comment explains it well enough. Not entirely sure if
Celery is supposed to handle cases like this, but we had at least one
case where it didn't, so I'd say it makes sense to have this?

To be explicit, I think this is safe because at this point, the
authenticated user is known to be the owner of the job, the database
says the job running on this specific runner, but the runner doesn't
know it. I don't think this could occur in any other situation.

 api/graph/schema.resolvers.go | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/api/graph/schema.resolvers.go b/api/graph/schema.resolvers.go
index 57c4089..41541cb 100644
--- a/api/graph/schema.resolvers.go
+++ b/api/graph/schema.resolvers.go
@@ -405,7 +405,12 @@ func (r *mutationResolver) Cancel(ctx context.Context, jobID int) (*model.Job, e
		if err != nil {
			return err
		if resp.StatusCode != 200 {

		// If the job was found like this in the database, but the
		// runner does not know about it, then something is wrong (e.g.
		// the runner crashed and rebooted). Go ahead and set it to
		// cancelled, so that it does not block anything.
		if resp.StatusCode != 200 && resp.StatusCode != 404 {
			return fmt.Errorf("Failed to cancel job")

Message ID
<20221124092646.418798-1-ch@bitfehler.net> (view parent)
DKIM signature
Download raw message

To git@git.sr.ht:~sircmpwn/builds.sr.ht
   023637a..5b4a40f  master -> master
Reply to thread Export thread (mbox)