No way to cancel `AsyncChannel` producer task when consumer task finishes early

[fumoboy007]

Server APIs commonly have a paging mechanism where the client can fetch one page after another. I am implementing a function that returns an AsyncChannel representing a stream of pages from a server. It looks like the following:

func allPages() -> AsyncThrowingChannel<Page, Error> {
   let channel = AsyncThrowingChannel<Page, Error>()

   Task {
      do {
         var currentPage = try await firstPage()

         while true {
            await channel.send(currentPage)

            guard let nextPage = try await currentPage.nextPage() else {
               break
            }
            currentPage = nextPage
         }

         channel.finish()
      } catch {
         channel.fail(error)
      }
   }

   return channel
}

This is a nice abstraction. However, consider the case where the consumer task breaks out of its reader loop early. There is currently no way for the consumer task to indicate to the producer task that it is done with the channel.

@phausler made a related change in #131 to make sure the producer task does not hang when the consumer task is done. However, the producer task still runs to completion, wasting resources.

Instead, I think the send method should throw CancellatonError so that the producer task can handle cancellation gracefully.

(CC @jonathanpenn who wrote a related Swift Forums post.)

[fumoboy007]

Or rather than throwing CancellationError, send could return a Bool. That would make it clear that send will not throw other types of errors.

[FranzBusch]

AsyncChannel is intended to allow communication between an unbounded amount of tasks. This allows for consumers and producers to come and go while keeping the channel up. In your example, you rather want a 1:1 relationship between consumer and producer. For this AsyncStream is way better suited and will terminate its continuation when the consumer goes away.

With my recent proposal to add backpressure to the external interface of AsyncStream you would have basically gotten the same API that you have on AsyncChannel but have it tied to a single consumer/producer pair. My proposal got returned for revision but I am currently thinking about adding the type to this package instead after we hit 1.0.0.

[fumoboy007]

Ah, looks like I misunderstood #131. That issue was about handling cancellations of the producer task, not the consumer task.

@FranzBusch Thanks for the clarification! SE-0406 looks great. 😊