Cancellation with async tasks

[tylerjames]

I have an action in my reducer that returns a .run effect that performs a couple async operations. Something like:

case .someAction:
  state.connectionState = .connecting 
  return .run { send in 
    let result1 = try await client.someOperation1()
    let result2 = try await client.someOparation2(result1)
    await send(.someActionResult(result2))
  }

Is there a way to apply a timeout to either the individual async calls inside the .run block or to the block itself? If any of these things gets stuck for whatever reason then my feature will get stuck in the .connecting state

[mbrandonw]

There is easy way to timeout async code in Swift, but you can do it manually, or make your own little operator to handle it:

case .someAction:
  state.connectionState = .connecting 
  return .run { send in 
    try await withThrowingTaskGroup(Void.self) { group in 
      group.addTask {
        let result1 = try await client.someOperation1()
        let result2 = try await client.someOparation2(result1)
        await send(.someActionResult(result2))
      }
      group.addTask {
        try await self.clock.sleep(for: .seconds(10))
        throw TimeoutError()
      }
      try await group.next()
      group.cancelAll()
    }
  }

[andreyz]

@mbrandonw I don't think group.cancelAll() is even necessary, as withThrowingTaskGroup will cancel all other sub-tasks once try await group.next() will throw TimeoutError (or one can also use built in CancellationError).

[mbrandonw]

I believe the group.cancelAll() is there for when the first task finishes, we want to cancel the clock.sleep. Otherwise the outer withThrowingTaskGroup will stay alive for as long as the timeout duration.

[andreyz]

Read your comment again, I get it now. Thank you for the opportunity to learn here.

[tylerjames]

Excellent, thanks @mbrandonw.

It is an "easy" way but certainly a bit more complicated than ising .timeout in Combine.

[mbrandonw]

Oh, I should mention that you can totally use the .timeout operator from combine if you want, after all Effect still is a publisher. You just have to do extra work to handle the error and erase it to effect:

  return .run { send in 
    let result1 = try await client.someOperation1()
    let result2 = try await client.someOparation2(result1)
    await send(.someActionResult(result2))
  }
  .timeout(...)
  // Use another operator to handle error
  .eraseToEffect()

The nice thing about staying in the async/await world is that Effect silently ignores any cancellation errors, so nothing extra to do there. So, might be nice to see how you could make your own Effect operator that does timeouts in purely async/await.

[tylerjames]

Wow that's not too bad either.

The funny thing is that I had tried typing .timeout after my .run block but Xcode must have been in "you're on your own" mode because it was not recognizing it.

[mbrandonw]

There's a chance you may need to do Effect.run instead of just .run. I believe when the generics change (as would be the case for getting the error to be Never), Swift can't infer the types.

[tylerjames]

@mbrandonw

Sorry to revive this old thread but I'm having some issues with timeout. I swear I have seen this work several times before but lately it just fails. I see the TimeoutError get thrown (by setting a breakpoint on that line) but the error just disappears after that. It doesn't get handled by the catch closure. And so my view just sits there in the connecting state indefinitely.

I've tried putting my try await withThrowingTaskGroup into a do/catch but even there the catch is not handled. Weirdly I think errors that are thrown by my client.initializeVideo and client.connect are handled because I've seen my Retry view show up occasionally.

Am I handling this error situation incorrectly? Here's my .run Effect:

return .run(operation: { [state] send in
    try await withThrowingTaskGroup(
      of: Void.self,
      body: { group in
        group.addTask {
          try await client.initializeVideo(state.channelArn)
          try await client.connect()
          await send(.connectResult(.success(true)))
        }
        
        group.addTask {
          try await Task.sleep(nanoseconds: 10 * NSEC_PER_SEC)
          throw TimeoutError.initializationTimeout
        }
        try await group.next()
        group.cancelAll()
      })
    
  }, catch: { error, send in
    await send(.connectResult(.failure(error)))
  })

[tylerjames]

Weirdly it's like the second task doesn't actually complete.
The group.cancelAll() doesn't get called if I throw an error from my Task.sleep block. If I just throw an error from the beginning of the first block then the cancelAll() does get called and the catch handler gets invoked.

Something weird going on

[tylerjames]

Is it maybe appropriate to do something like this:

group.addTask {
  try await Task.sleep(nanoseconds: 10 * NSEC_PER_SEC)
  await send(.connectResult(.failure(TimeoutError.initializationTimeout)))
}
try await group.next()
group.cancelAll()

Basically sending an error result instead of throwing an error and allowing my sleep Task to just complete normally and the group.cancelAll() to cancel the timed-out task?

[mbrandonw]

Yeah, if you are just sending along the error to the send, then this last code snippet seems simplest. It's still strange that the previous code was not working. Is TimeoutError a whole new type, or is it a typealias of CancellationError?

[tylerjames]

It was a pretty simple error type like this:

  enum TimeoutError: Error, Equatable {
    case initializationTimeout
    case connectionTimeout
  }

I'll try to poke around it some more. I've got it working with just passing the action to send but it's a little disconcerting that the throw didn't seem to be working