Handling effect cancellation when changing state

[lukeredpath]

There has been some previous discussion on whether or not TaskResult should not wrap cancellation errors, see:

#1934
#2281

I think the conclusion was that this is the correct behaviour as you might need to react to cancellation like any other error to clean up some state (e.g. some kind of requestInFlight: Bool property) and that in general, automatic effect cancellation when some feature state goes away is now handled by the built-in navigation tools.

However, I still have one case in my app which I imagine is common and is not currently managed by the built-in navigation tools (and I'm not sure how I would use them) where I have to manage this cancellation manually and that is when the user gets logged out (either explicitly or for some other reason).

The user's session state is managed by a var session: Session.State property in the root of our app feature state, is non-optional and is an enum value:

enum Session.State {
  case loggedIn(LoggedInFeature.State)
  case loggedOut(LoggedOutFeature.State)
}

The session feature manages the logout process which can be summarised as:

case .handleLogout:
  state = .loggedOut(...)
  return .cancel(id: CancelId.loggedInRequests)

The intention here is to cancel any in-flight logged-in network requests when the user is logged out - the way we do this is that we override our apiClient dependency on the LoggedInFeature() reducer so that all requests are wrapped with a single global cancellation ID (CancelId.loggedInRequests) - this allows the session reducer to trigger the cancellation of all API requests started within the LoggedInFeature and any of its child features with a single .cancel(id:) call.

This works as expected but now in the process of updating to TCA 1.4.0, I'm no longer using TaskResult and am just using Result. This means that after transitioning to the .loggedOut state, I can receive logged in actions for the cancelled requests, e.g. .loggedIn(.someRequest(.failed(CancellationError()))) - this causes purple runtime warnings in dev builds and more importantly, can cause test failures (and we have some tests explicitly testing this cancellation scenario).

What would be the best way to handle this?

[mbrandonw]

Hi @lukeredpath, are you using the ifCaseLet reducer operator in order to compose LoggedInFeature and LoggedOutFeature into the parent? If so, then I would expect effects to be automatically torn down when the case of the state switches. Is that not the case?

Would it be possible for you to cook up a really simple unit test that demonstrates the behavior you are seeing? That would help us figure out how to move forward.

[lukeredpath]

Actually I'm using Scope instead of ifCaseLet - I think I'd forgotten that existed or for some reason in my head the ifXXX modifiers were just for dealing with optional state. All of my Destination reducers use Scope for each case (as do the TCA docs) so I guess I didn't see my Session reducer as being any different.

[mbrandonw]

That's true that Destination reducers just use Scope, but then they are put in an ifLet and so that handles cancellation for them.

You should think of ifCaseLet as the reducer version of if case let, which is for unwrapping any enum state, not just optionals. Does using ifCaseLet solve your problems?

[lukeredpath]

Sounds like it might - I will take it for a spin and report back.