fix: duplicate "Are you sure?" dialogs after connecting a WordPress channel#1641
Open
giladresisi wants to merge 1 commit into
Open
fix: duplicate "Are you sure?" dialogs after connecting a WordPress channel#1641giladresisi wants to merge 1 commit into
giladresisi wants to merge 1 commit into
Conversation
areYouSure() opens its dialog indirectly: it emits an 'open' event on a module-level decisionModalEmitter, and the mounted DecisionEverywhere component listens for that event and opens the modal. DecisionEverywhere subscribed in a useEffect with no cleanup, so every mount added another listener that was never removed. Most channel connect flows redirect via window.location.href, a full page reload that recreates the module (and a fresh, empty emitter), so the leak was never visible. WordPress connects with customFields, which returns to the app via client-side router.push instead. That unmounts and remounts MantineWrapper (and DecisionEverywhere) without a reload, leaving a second, stale listener subscribed. A single areYouSure() call then fired both listeners and opened two identical stacked dialogs; clicking a button closed only the top one, so a duplicate stayed on screen for every channel until a manual refresh. Remove the leaked listener on unmount (off the exact handler we added) so exactly one listener is subscribed at any time across mount/unmount cycles. Known limitation: this relies on at most one DecisionEverywhere being mounted at a time, which holds today because every MantineWrapper lives in a mutually-exclusive route group (and embedded previews run in iframes). If two MantineWrappers were ever mounted simultaneously in the same document, two listeners would coexist and duplicates could return; that would need a separate fix (e.g. opening the dialog directly on the store, or a stable modal id). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Contribution-checker quality warning Heuristics that flagged:
If this is a genuine contribution, please add detail to your PR description and tighten the diff scope before reviewers look at it. |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
After connecting a WordPress channel, the "Are you sure?" confirmation dialog (e.g. when deleting a channel) started appearing twice. Clicking Yes or No only dismissed one copy, leaving a duplicate stuck on screen. It affected every channel, not just WordPress, and only cleared after a full page refresh.
Why this matters
This is a confusing, broken-feeling UX on a common, destructive action (deleting channels). A user could think their click "didn't work", and a leftover dialog blocking the screen looks like the app is stuck — all triggered simply by having connected WordPress earlier in the session.
Why it only showed up after WordPress
Most channels finish connecting with a full page reload, which resets everything. WordPress finishes with an in-app navigation (no reload), and that difference left the confirmation dialog's internal listener subscribed twice, so it opened a duplicate. Full technical root-cause is in the commit message.
The fix
The confirmation dialog is opened by a component (
DecisionEverywhere) that subscribed to an event emitter in auseEffectwithout cleanup, so it leaked a listener on every unmount/remount. This adds the missing cleanup, so exactly one listener is ever subscribed and only one dialog opens. Minimal change, preserves the existing design; per-dialog close behaviour is unchanged.There is a documented known limitation in the commit message (this assumes a single mounted modal wrapper, which holds today); it's intentionally out of scope here.
🤖 Generated with Claude Code