Sheet dismiss effect fails to dismiss presentation after parent reducer state transition

[OguzYuuksel]

Description

Steps to reproduce:

1. Start in .online state
2. Present a sheet
3. Start a timer effect that will call dismiss() after 5 seconds
4. Transition to .offline state (timer gets cancelled as expected - "cancelled" prints)
5. Transition back to .online state (timer restarts via .send(.online(.modal(.presented(.sheet(.timer))))))
6. After 5 seconds, "will dismiss" prints but the sheet remains visible

DismissEffectBehavior.mov

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

Expected: The sheet should dismiss after the timer completes.

Actual behavior

Actual: The dismiss dependency has no effect, sheet remains visible.

Reproducing project

There are several options to solve that

1. Dismissing modal by setting modal state to nil from parent reducer.
2. Having dynamic ID for the sheet modal and resetting it to different id after parent status change.

My real case is much complex and there are some reasons to have module based identity instead of instance based identity for this specific case I want SwiftUI to recognize it's the same presentation semantically, even if the parent state transitions.

TCADismissEffect.zip

The Composable Architecture version information

1.23.1

Destination operating system

iOS 26.1

Xcode version information

Version 26.1.1 (17B100)

Swift Compiler version information

swift-driver version: 1.127.14.1 Apple Swift version 6.2.1 (swiftlang-6.2.1.4.8 clang-1700.4.4.1)
Target: arm64-apple-macosx26.0

[OguzYuuksel]

I debugged the issue in the repo, it's related to NavigationID and PresentationReducer effect handling. I am also worried about overall behavior of effects after deep linking.

[OguzYuuksel]

I’ve tried to fix the issue. All tests are passing, but I’m not entirely sure if my approach is correct. Some big-picture insight is needed to understand the full impact of my changes.
#3821

[stephencelis]

This is fixed in 2.0. @OguzYuuksel we appreciate the detailed project and PR to fix, but are a little hesitant to merge with a new major release on the horizon. We are still open to getting a fix merged, but are a little worried about regressions in existing apps, and don't know if/when we'll have time to fully wrap our heads around the changes there. Let us know what you think!