Revisit Cancelation behavior.

[sergdort]

Hi everyone!

We've been having an issue in our codebase with regards to cancelation behavior and It was quite a surprise for me to learn that cancellables for all effects are stored in the global cancelation bag

Let me describe the potential situation that may occur (which has happen to us actually). Let's say we have this setup

struct ProductLiveUpdatesFeature: ReducerProtocol {
@Dependency(\.prodcutLiveUpdatesService) var service: ProdcutLiveUpdatesService

func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
    switch action {
        case .startUpdates:
            return service.getUpdates(for: state.product).map(Action.itemsDidChange)
                .cancellable(id: CancelToken.cancelUpdate(state.product.id), cancelInFlight: true)
        case .itemsDidChange(let items):
            state.items = items
            return .none
        case .stopUpdates:
            return .cancel(id: CancelToken.cancelUpdate(state.product.id))
        }
    }

    struct State {
        var product: Product
        var items: [Item]
    }

    enum Action {
        case startUpdates
        case stopUpdates
        case itemsDidChange([Item])
    }

    enum CancelToken: Hashable {
        case cancelUpdate(ProductId)
    }
}

So for example with a multistore setup (or even without mutlistore setup) let's say we have two screens that display the same product

// In one place of the app 
let store1 = StoreOf<ProductLiveUpdatesFeature>(state: State(product: product))

// we start live updates

store1.send(.startUpdates)

// Some where else
let store2 = StoreOf<ProductLiveUpdatesFeature>(state: State(product: product))

// we start live updates
store2.send(.startUpdates)

// And if we later do
store1.send(.stopUpdates) // this will stop live updates of the store2 as well due to the shared cancelation bag

My main issues with this are:

• It breaks mental contract where life cycle of an Effect is not tight with lifecycle of its parent (the Store or Reducer instance)

[mbrandonw]

Hi @sergdort, yeah this is how TCA has always worked. Due to its current design there is nowhere else to cancelables other than the global dictionary. If you need to differentiate between the same feature running twice you could add a UUID to the feature state and mix that into the cancellation ID.

We do have near future plans for the library that will properly silo effects in their respective features, but it's going to take time to get there, and we're not yet sure if that can be done in a backwards compatible 1.x release, or if it will be 2.0.