Fast async actions fired from .run result in actions on nil state during dismissal

[ghost]

In an application that runs an async timer in a dismissable "SheetScene" as follows:

            case .begin:
                // Sufficiently fast updates on this results in parent receiving a child action when child state was "nil" via this send, when this scene is dismissed...
                return .run { send in
                    for await result in await ThingWithManyResults.asyncStream(name: "Sheet Scene", timeInterval: 0.1) {
                        await send(.latestOfManyAsyncResults(result))
                    }
                }

where the .begin action is started like this:

        var body: some SwiftUI.View {
            WithViewStore(self.store, observe: { $0 }) { viewStore in
                VStack {
                    Text(viewStore.latestOfManyAsyncResults)
                    Button(action: { viewStore.send(.dismiss) }) {
                        Text("Dismiss")
                    }
                }
                .task { await viewStore.send(.begin).finish() }
            }
        }

Dismissing this SheetScene (which is both running the timer and asynchronously receiving the timer events) results in a cancellation of the timer (as expected because of the finish()), but it looks like the scene is fully gone while actions are still in-flight from await send(.latestOfManyAsyncResults(result)), because the logs report This action was sent to the store while state was "nil".

There is a full app demonstrating this at [link to TCAQuestion0002 removed, outdated] (make sure you're on the TCAQuestion0002 branch for this, which should be the default). To see the issue in the app, click "Show Sheet" to navigate to the SheetScene, let the timer run for a moment, then click "Dismiss"

How can this state was "nil" error be prevented? As far as I know, using await send(.latestOfManyAsyncResults(result)) to deliver the actions from the .run block is the only way to update the state... but because this update occurs asynchronously, the scene might be gone by the time the action arrives.

[ghost]

Would some form of debouncing help here?

[stephencelis]

@wilsonmhpn We have plans to suppress these kinds of warnings in the future, but for now we think it's safe to ignore them, and they shouldn't affect release builds of your application. They merely try to point out when the store is unable to process those final actions, which it sounds like is OK in this case?

[ghost]

Sounds good, thanks.