Propagating cancellation to an enqueued task

[Cykelero]

I'm trying to wrap my head around this.

From some async code, I'm enqueing a task onto a queue:

// Outer task
let task = queue.addOperation {
	// Inner task
	doFirstThing()
	guard !Task.isCancelled else { return }
	doSecondThing()
}

return await task.value

If the outer task gets cancelled, the inner task doesn't get cancelled too—there's no parent-child relationship.

Would propagating cancellation be achievable?
And would it be a good idea at all? (i.e. does my need to propagate cancellation suggest I'd be better served by something other than a queue)

The queue is used to make sure a given Web resource is only being written to by a single operation at a time. Or, in other words, my enqueing is not fire-and-forget; the tasks are kept track of, surfaced in the app's UI, and the user can elect to cancel them.

[mattmassicotte]

Hmmm. There is a test that attempts to validate this exact thing, and it passes. These kinds of things can be racy though. Could it be the test is wrong? Or perhaps your code is actually being canceled after the check is performed?

Queue/Tests/QueueTests/AsyncQueueTests.swift

Line 209 in cc86ecf

func testCancelOperation() async throws {

[Cykelero]

Doesn't the test check that you can cancel the inner task?
What I'm trying to achieve is propagating a cancellation of the outer task, the the inner one. E.g.:

let outerTask = Task {
	let innerTask = queue.addOperation {
		try await Task.sleep(for: .seconds(3))
		print("Inner task was not canceled")
		
		return try await doSomeWork()
	}
	
	try await Task.sleep(for: .seconds(2))
	print("Outer task was not canceled")
	
	return try await innerTask.value
}

try await Task.sleep(for: .seconds(1))

outerTask.cancel()

This prints “Inner task was not canceled”.

[Cykelero]

So, this seems to work:

let task = queue.addOperation {
	return try await doSomeWork()
}

return try await withTaskCancellationHandler {
	try await task.value
} onCancel: {
	task.cancel()
}

I'm still very curious to get your opinion on this—whether or not it's likely to be a good idea.

The code in that last return could easily be wrapped in some utility propagatingCancellation(task: Task) method, too.

[mattmassicotte]

Ohhh, I misunderstood that you had wrapped all this up in another Task! Yes using withTaskCancellationHandler can do this.

But, I think you should be thinking really hard about using a pattern like this. Your outer Task no longer has ordering with respect to its caller. Are you certain this is not introducing races?

[Cykelero]

I think it is. The outer task is started from a UI callback (e.g. when the user clicks the Push button), so its resolution doesn't have a strong ordering requirement.

The goal of that outer Task {} is to keep track of the long-running operation, both to display its progress, and allowing it to be cancelled by the user:

So if the outer task is cancelled, the inner task really needs to be cancelled to—regardless of whether it's waiting for its turn in a queue, or not.

[mattmassicotte]

What happens if the user pressed the button and before the outer task is executed the user presses another button that accesses that queue?

[Cykelero]

Sorry, I don't understand. By “before the outer task is executed”, do you mean before it's started, or ended?
Either way I can't think of what sort of issue could result. What do you have in mind?

[mattmassicotte]

Before it is started.

Button press 1:

let outerTask1 = Task { print("1" }

Then later, button press 2:

let outerTask2 = Task { print("2" }

This can result in the output:

2
1

In your specific usage it may not matter though!

[Cykelero]

Ah, I think I get it! If the app's threads are already busy, the first press' outer task could get delayed to after the second button press, and so get ordered incorrectly.

I'll probably leave things like this for now—that situation wouldn't be too problematic—but I'll keep an eye out for this sort of behavior. Thank you for the explanations!

[mattmassicotte]

Even if the threads are not busy that could happen! Task is entirely unordered in every way. I'm slightly surprised this is ok but you also need a queue, but I totally believe it could be true.

And you are very welcome!