EffectTask.cancel(id:) doesn't work if the reducer that starts the effect is different from the one cancelling it.

[AndreaRomani]

Hello! 👋 Opening this discussion following @stephencelis request on Slack 🙂

Since the recent navigation tools have been released (0.54) I noticed an unexpected behaviour with respect to effects cancellation.

The issue is that sometimes effects that are marked as .cancellable(id: id) aren't cancelled by a corresponding .cancel(id: id). In particular this happens if the reducer that starts the effect is different from the one that cancels it.
By investigating a little bit I think I understood that this is related to the fact that effect cancellation requires not only that the cancellation id matches, but also that the navigationIDPath is the same.

Even though I understand the reasons for this choice and I recognize its benefits for handling cancellation of effects in the context of navigation, I think this could be too restrictive in some cases, also because there's no indication of this fact in the API.

Suppose for example that I have a Child feature that exposes a start API to return its initial state to the Parent and start a long living effect.

struct ParentReducer: ReducerProtocol {
  struct State: Equatable {
    var child: ChildReducer.State?
  }
  enum Action: Equatable {
    case startChild
    case child(ChildReducer.Action)
  }
  var body: some ReducerProtocolOf<Self> {
    Reduce { state, action in
      switch action {
      case .startChild:
        let (childState, childEffect) = ChildReducer().start()
        state.child = childState
        return childEffect.map(Action.child)

      case .child(.cancel):
        state.child = nil
        return .none

      case .child:
        return .none
      }
    }
    .ifLet(\.child, action: /Action.child) {
      ChildReducer()
    }
  }
}

// MARK: - ChildReducer

struct ChildReducer: ReducerProtocol {
  struct State: Equatable {}
  enum Action: Equatable {
    case cancel
  }
  var body: some ReducerProtocolOf<Self> {
    Reduce { _, action in
      switch action {
      case .cancel:
        return .cancel(id: CancelID.start) // <-- this doesn't actually cancel the effect in `start`.
      }
    }
  }
  enum CancelID {
    case start
  }
  func start() -> (State, EffectTask<Action>) {
    (
      State(),
      .run { _ in
        // simulate a long living effect
        try await Task.never()
      }
        .cancellable(id: CancelID.start)
    )
  }
}

In this way any long living work started in childEffect wouldn't be torn down:

• neither by dismissing the Child feature
  • this makes sense, after all it's the parent that started the effect
  • although, it would be nice to have a way to explicitly tie the effect to che Child feature
• nor within the Child feature itself, by marking the effect as .cancellable and using .cancel, which instead is unexpected.

As a consequence the following test - which passes successfully on 0.53 - fails because the child effect isn't torn down.

@MainActor
class CancellationTests: XCTestCase {
  func testCancellation() async {
    let store = TestStore(initialState: ParentReducer.State(), reducer: ParentReducer())
    await store.send(.startChild) {
      $0.child = ChildReducer.State()
    }
    await store.send(.child(.cancel)) {
      // should also cancel the long living effect
      $0.child = nil
    }
    await store.finish()
  }
}

Is this behaviour intended? Are there any best practices to handle this use case?

[mbrandonw]

Hi @AndreaRomani, yeah this behavior is intended. It is what allows one to present the same feature multiple times (such as in a navigation stack) and not have the effects of one instance of the feature trample on the effects of another instance of the feature. And in general, it seems problematic for child features to be able to cancel parent effects like this. We even have changes coming to TCA in the somewhat near feature that will make the compartmentalization of reducer effects even a bit stronger.

I think the better pattern for what you have described here is for the child feature to communicate to the parent that it wants something done, say via a delegate action, and then have the parent do the cancellation. I don't think we yet have any documentation about the delegate action pattern, but we did discuss it in this episode.