Support cancellation

[crazytonyli]

From the uniffi-rs doc:

We don't directly support cancellation in UniFFI even when the underlying platforms do. You should build your cancellation in a separate, library specific channel;

Our use case is more complicated: the native code calls the Rust library's async functions, which are not cancellable, and the Rust async functions call the native RequestExecutor to make HTTP requests ("foreign future"), which are also not cancellable.

As a library whose main purpose is sending HTTP requests to WordPress sites, we should support cancellation: if the user cancels posting a comment, the underlying HTTP request should be cancelled.

[crazytonyli]

I have verified this issue, where HTTP requests can not be cancelled, exists in Swift. Not sure about Kotlin, though. /cc @oguzkocer

[oguzkocer]

@crazytonyli I don't think Rust is involved in this part of the process. We intentionally built Rust to be a "dummy" implementation. It builds the details of the request and then calls the request executor to carry it out. Unless Rust layer needs to make a decision and calls 'cancel' itself, I don't see any reason to complicate that layer.

In my opinion, this is part of the request executor layer and for Kotlin, @adalpari implemented canceling media upload requests in #817.

Let me know if I am missing a use-case where we need to involve Rust.

[crazytonyli]

I don't have a solution. The wrappers are likely to be the main driver here, considering uniffi-rs straight up does not support cancellation.

The Swift wrapper has a similar thing to cancel uploading media. But that's built for that specific endpoint. It's not a general solution that applies to all API calls. This issue here is more about having a general solution, so that all API calls can be cancelled if needed.

[adalpari]

Out of curiosity: what long-run actions other than media uploading would the user want to cancel?
I mean, when posting a comment, is there enough time to offer a cancel action?

[crazytonyli]

Probably not explicitly cancelled by users. The app does not offer many features like that.

From the consumer's point of view, since iOS SDK async functions do handle cancellation, it's more intuitive to work with cancellable async functions.

For example,

let vanilla = Task {
  try await URLSession.shared.data(for: getCommentRequest)
}
vanilla.cancel() // The HTTP request will be cancelled.

let rs = Task {
  try await api.comments.retrieveWithViewContext(2)
}
rs.cancel() // The HTTP request should be cancelled too, just like the `URLSession` call above.

Sometimes, the API calls in wordpress-rs are invoked deep into the call chain, the consumer won't even know that an uncancellable API call is invoked. For example:

func createApplicationPassword() async throws {
  try await loadingSite()
  try await loadingUsername()
  try await sendHTTPRequestToCreateApplicationPassword()
  try await saveApplicationPassword()
}

// Let's say the `loadingUsername` calls wordpress-rs, and the other functions
// use `URLSession` underneath and can be cancelled.
// `loadingUsername` should support cancellation too, so that the whole process is cancellable.

let task = Task { try await createApplicationPassword() }
task.cancel() // The creating application password process should be aborted.

Again, we may not have many task.cancel() to explicitly cancel some HTTP requests in the codebase. Still, it's pretty standard to put loading data calls in SwiftUI's .task API API, which manages tasks for us and cancels them when the user exits the SwiftUI view. And when the task is cancelled, the loading data calls should be cancelled too.