chore(runway): cherry-pick fix: prevent unnecessary reward navigation on account change#21277
Merged
Conversation
#21264) When you reinstalled the app and reimported an SRP where the first account/group was tied to the rewards program, you wouldn't see the rewards gtm modal as its logic wouldn't trigger. In the same session, when switching to an account that wasn't tied to the rewards program yet, the gtm modal would trigger a navigation to the onboarding/gtm modal but then we'd detect that there was opted in for another/other accounts (i.e. primary) and the rewards dashboard would be seen. To prevent this, in the logic that spawns the gtm modal, as soon as we detect a `subscriptionId`, we set the gtm modal seen storage prop to true, preventing it to be spawned/navigated to when changing an account that had no `subscriptionId`. Minor extra fix; as we're moving ahead with prod readiness, we are switching the geo check URI to prod. CHANGELOG entry: null Fixes: #21252 1. Reinstall app 2. import existing SRP where primary account (first) is already opted in to rewards program but second/other accounts not 3. the primary view/wallet view will load and no gtm modal should open 4. switch to an account that is not tied to the rewards program. 5. Before this fix, you would've been redirected to the rewards program. With this fix, nothing should happen. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Marks the rewards intro modal as seen when a subscription exists and on intro step mount to prevent unwanted navigation, simplifies the intro modal, and forces the geolocation service to use the PROD URL; tests updated accordingly. > > - **Rewards Onboarding**: > - Move `REWARDS_GTM_MODAL_SHOWN` persistence to `OnboardingIntroStep` (set on mount) and simplify `RewardsIntroModal` to be presentational only. > - In `useRewardsIntroModal`, if `subscriptionId` exists, set `REWARDS_GTM_MODAL_SHOWN` to `true` and skip navigation. > - Minor robustness: swallow errors in `RewardsController:isOptInSupported` check. > - **Services**: > - `RewardsDataService.fetchGeoLocation` now always uses `GEOLOCATION_URLS.PROD`. > - **Tests**: > - Update/relocate storage expectations to `OnboardingIntroStep` and `useRewardsIntroModal`. > - Adjust geolocation tests to expect PROD URL irrespective of environment. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 63407dd. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
Contributor
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
Collaborator
|
No release label on PR. Adding release label release-7.57.0 on PR, as PR was cherry-picked in branch 7.57.0. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
Description
When you reinstalled the app and reimported an SRP where the first
account/group was tied to the rewards program, you wouldn't see the
rewards gtm modal as its logic wouldn't trigger. In the same session,
when switching to an account that wasn't tied to the rewards program
yet, the gtm modal would trigger a navigation to the onboarding/gtm
modal but then we'd detect that there was opted in for another/other
accounts (i.e. primary) and the rewards dashboard would be seen.
To prevent this, in the logic that spawns the gtm modal, as soon as we
detect a
subscriptionId, we set the gtm modal seen storage prop totrue, preventing it to be spawned/navigated to when changing an account
that had no
subscriptionId.Minor extra fix; as we're moving ahead with prod readiness, we are
switching the geo check URI to prod.
Changelog
CHANGELOG entry: null
Related issues
Fixes: #21252
Manual testing steps
to rewards program but second/other accounts not
With this fix, nothing should happen.
Note
Marks the rewards GTM intro as seen on intro mount and when a subscription exists to avoid unwanted navigation, and switches geolocation to the PROD endpoint; updates tests accordingly.
REWARDS_GTM_MODAL_SHOWNtoOnboarding/OnboardingIntroStep.tsxon mount; simplifyRewardsIntroModal.tsxto presentation-only.useRewardsIntroModal.ts, setREWARDS_GTM_MODAL_SHOWNwhensubscriptionIdexists to prevent GTM modal navigation on account switch.rewards-data-service.fetchGeoLocation()now always usesGEOLOCATION_URLS.PROD.Written by Cursor Bugbot for commit 64ebc87. This will update automatically on new commits. Configure here.
bffddee