Are subsequent effects executed (and cancelled) as part of the same Task tree?

[sixten]

I'm trying to debug an odd situation we're seeing in one of our apps where an effect that ultimately calls our login API seems to be aborting in the middle. This effect is not, itself, marked as cancelable. The URLSession.data(for:) call is throwing a URLError(.cancelled), and the code that catches that sees Task.isCancelled returning true. This says to me that somewhere else, this task (or a parent) is being cancelled, but I'm having a hard time identifying where that might be.

This earlier discussion describes a very similar issue, and while it wasn't resolved, @Sajjon's question about using the task() modifier got me thinking about why that would matter.

In our case, the effect that sees the cancellation is several chained actions & effects removed from task(), but does ultimately derive its initial "impulse" from that modifier sending Action.View.task to our store. The chain of execution looks something like:

• The view's task() modifier sends Action.View.task to the store.
• The code in the reducer handles that action and returns an effect that send Action.Internal.foo to the store.
• The code in the reducer handles that action and returns an effect that send Action.Internal.bar to the store.
• The code in the reducer handles that action and returns an effect that attempts to log the user in, which is where we're seeing the cancellation.

Does all of this happen within the same task (or task tree)? Would cancelling the original task() propagate all the way through to the currently-executing login effect? It had never occurred to me before that that would be the case, but if so, it might explain the situation we're seeing.

And, if this is the case, is there a good way to break that relationship? If we could prevent the cancellation of the original task(), great. But is there a way to "detach" the subsequent effects so that they continue to run regardless?

[mbrandonw]

Hi @sixten, you are correct that if sending action1 causes an effect to start that sends action2 which in turn also starts an effect, then the cancellation of the first effect will also cancel the second effect. This is a consequence of everything being run by the RootStore, and we agree that it can be a bit surprising. Fortunately we do have changes coming to the library that will allow us to fix this longstanding problem.

For the time being I have just added a test to capture this behavior (#3499). I can't think of a simple workaround right at this moment. I do have a question though: are you using the library's navigation tools (e.g. @Presents, ifLet, etc?). If so, then there typically isn't much of a need for the task modifier, and you can just use onAppear, since those tools take care of effect cancellation automatically. And they only cancel effects when the feature is fully dismissed, not just when it disappears, which can happen when navigating away from a feature even if that feature is still "present."

[sixten]

Thanks for the confirmation, Brandon!

I'm not sure that I'd describe the current behavior as a problem now that I understand it, but I had the wrong mental model. I think I'd been imagining the effects being handed back to the store by the reducer, and then running independently somehow. But given that the reducer is awaiting those effects — and the effects, in turn, any actions they send — I'm not sure how I got that idea. 😅

We are using the task modifier in quite a few places, but primarily for things like listening to change streams and such. The login UI is one of the few places where . I think I gravitated toward task over onAppear at least in part because it's already an async context, and felt a little cleaner. We're definitely also using many of the navigation tools provided by the library.