Skip to content

feat: add favorite when an alert is created - #33965

Merged
juanmigdr merged 5 commits into
mainfrom
feat/add-to-watchlist-on-alert-creation
Jul 30, 2026
Merged

feat: add favorite when an alert is created#33965
juanmigdr merged 5 commits into
mainfrom
feat/add-to-watchlist-on-alert-creation

Conversation

@juanmigdr

@juanmigdr juanmigdr commented Jul 29, 2026

Copy link
Copy Markdown
Member

Description

Automatically adds a token to the user’s watchlist after they successfully create their first price alert for that token. This reuses the existing watchlist add mutation, only applies to new alert creation when the token had no existing alerts, and leaves edits, failed saves, and tokens with existing alerts unchanged; focused tests cover both the save-flow behavior and the screen-level flag calculation.

Segment schema changes: https://github.com/Consensys/segment-schema/pull/691

Changelog

CHANGELOG entry: add favorite when an alert is created

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/ASSETS-3699

Manual testing steps

Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]

Screenshots/Recordings

Before

After

Pre-merge author checklist

Performance checks (if applicable)

  • I've tested on Android
    • Ideally on a mid-range device; emulator is acceptable
  • I've tested with a power user scenario
    • Use these power-user SRPs to import wallets with many accounts and tokens
  • I've instrumented key operations with Sentry traces for production performance metrics

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

  • I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
  • I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

Note

Low Risk
Scoped UX change reusing an existing mutation, gated on successful create with no existing alerts; behavior is covered by unit tests.

Overview
After a successful first price alert for a token, the app now adds that asset to the watchlist via the existing watchlist add mutation and fires WATCHLIST_TOKEN_ADDED with source price_alert_creation.

CreatePriceAlertView passes shouldAutoWatchlistOnCreate into useAlertSaveFlow only when the user is creating (not editing) and there are no existing absolute or percent alerts for that asset. Edits, failed saves, and additional alerts for tokens that already have alerts do not touch the watchlist.

Tests cover the save-flow hook and the screen-level flag wiring. WatchlistAnalytics.ADD_SOURCE.PRICE_ALERT_CREATION was added for analytics.

Reviewed by Cursor Bugbot for commit b9f40e1. Bugbot is set up for automated code reviews on this repo. Configure here.

@juanmigdr
juanmigdr requested a review from a team as a code owner July 29, 2026 08:43
@metamask-ci

metamask-ci Bot commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

PR template — items to address before "Ready for review"

Warnings — informational, address before merging:

  • Manual testing steps still contain template content (the Gherkin example title or a [...] placeholder). Replace with real steps, or write N/A — <reason>.
  • Screenshots/Recordings section is empty. Add an image/video for user-facing changes, logs/console output for non-user-facing changes, or write N/A if no evidence is applicable.
  • Pre-merge author checklist has unchecked items (e.g. "I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards."). Every box must be consciously checked — see docs/readme/ready-for-review.md.

See docs/readme/ready-for-review.md for the full Definition of Ready for Review.

@github-actions github-actions Bot added size-M risk:medium AI analysis: medium risk labels Jul 29, 2026
juanmigdr and others added 4 commits July 29, 2026 16:30
…34003)

<!--
Please submit this PR as a draft initially.

Do not mark it as "Ready for review" until this PR meets the canonical
Definition of Ready For Review in `docs/readme/ready-for-review.md`.

In short: the template must be materially complete (not just section
titles
present), all status checks must be currently passing, and the only
expected
follow-up commits must be reviewer-driven.
-->
<!--
mms-check directive vocabulary — read by
.github/scripts/shared/pr-template-checks.ts
at module load to build the validation plan. Directives are invisible in
rendered
markdown and must NOT be removed or edited without updating the
validator registry.

  type=text           Section must contain non-placeholder prose.
  type=changelog      Section must have a valid CHANGELOG entry: line.
type=issue-link Section must have a Fixes:/Closes:/Refs: line with a
value.
type=manual-testing Section must have real testing steps or an explicit
N/A.
type=screenshot Section must have evidence (image/URL) or an explicit
N/A.
type=checklist Section must have all checkboxes consciously checked.
required=true|false Whether a missing/invalid section runs the validator
at all.
blocking=true|false Whether a failure of this check fails the CI
workflow.
Default: false — failures are shown as warnings in the sticky
                      comment but do not block the PR.

Sections without a directive are checked for structural presence only.
-->

## **Description**

<!-- mms-check: type=text required=true -->

<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->

## **Changelog**

<!-- mms-check: type=changelog required=true blocking=true -->

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry:

## **Related issues**

<!-- mms-check: type=issue-link required=true -->

Fixes: https://consensyssoftware.atlassian.net/browse/ASSETS-3665

## **Manual testing steps**

<!-- mms-check: type=manual-testing required=true -->

```gherkin
Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]
```

## **Screenshots/Recordings**

<!-- mms-check: type=screenshot required=true -->

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

<!-- [screenshots/recordings] -->

### **After**

<!-- [screenshots/recordings] -->

## **Pre-merge author checklist**

<!-- mms-check: type=checklist required=true -->

<!--
Every checklist item must be consciously assessed before marking this PR
as
"Ready for review". A checked box means you deliberately considered that
responsibility, not that you literally performed every action listed.

Unchecked boxes are ambiguous: they are not an implicit "N/A" and they
are not
a silent "skip". See `docs/readme/ready-for-review.md` for the full
checklist
semantics.
-->

- [ ] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [ ] I've completed the PR template to the best of my ability
- [ ] I've included tests if applicable
- [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

#### Performance checks (if applicable)

- [ ] I've tested on Android
  - Ideally on a mid-range device; emulator is acceptable
- [ ] I've tested with a power user scenario
- Use these [power-user
SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93)
to import wallets with many accounts and tokens
- [ ] I've instrumented key operations with Sentry traces for production
performance metrics
- See [`trace()`](/app/util/trace.ts) for usage and
[`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274)
for an example

For performance guidelines and tooling, see the [Performance
Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers).

## **Pre-merge reviewer checklist**

<!--
Reviewer checklist items follow the same semantics as the author
checklist: an
unchecked box is ambiguous, a checked box means the reviewer consciously
assessed that responsibility. See `docs/readme/ready-for-review.md`.
-->

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Analytics-only instrumentation on an existing auto-watchlist path; no
change to watchlist or alert save behavior beyond event tracking.
> 
> **Overview**
> When a user creates their **first** price alert for an asset and the
app auto-adds that token to the watchlist, the flow now emits
**`WATCHLIST_TOKEN_ADDED`** with `source: price_alert_creation` and
`asset_type` from `getWatchlistAssetType`.
> 
> `WatchlistAnalytics.ADD_SOURCE.PRICE_ALERT_CREATION` was added in
watchlist analytics constants. **`useAlertSaveFlow`** fires the event
right after the existing watchlist mutation; behavior is unchanged for
edits, assets that already have alerts, or failed saves. Tests assert
the new event payload.
> 
> **ManagePriceAlertsView** only renames the `analyticsPropsForAlert`
parameter (`alert` → `priceAlert`).
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
4aabb59. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
@github-actions

Copy link
Copy Markdown
Contributor

🔍 Smart E2E Test Selection

  • Selected E2E tags: None (no tests recommended)
  • Selected Performance tags: None (no tests recommended)
  • Risk Level: low
  • AI Confidence: 88%
click to see 🤖 AI reasoning details

E2E Test Selection:
The PR modifies Price Alerts and Watchlist components:

  1. CreatePriceAlertView.tsx: Adds shouldAutoWatchlistOnCreate logic to auto-add a token to the watchlist when creating the first price alert.
  2. useAlertSaveFlow.ts: Integrates useTokenWatchlistAddItemMutation to auto-add assets to watchlist on first price alert creation, with analytics tracking.
  3. watchlistAnalytics.ts: Adds a new ADD_SOURCE.PRICE_ALERT_CREATION analytics constant.
  4. ManagePriceAlertsView.tsx: Pure cosmetic variable rename (alertpriceAlert) with zero functional impact.
  5. Test files: Unit test updates for the above changes.

These changes are entirely within the Price Alerts and Watchlist feature area. None of the available E2E smoke tags cover Price Alerts or Watchlist functionality directly. The changes do not affect:

  • Core navigation/TabBar components
  • Confirmation flows
  • Account management
  • Network management
  • Swap/bridge flows
  • Snaps
  • Browser
  • Onboarding

The changes are well-contained feature additions with unit test coverage. No shared components that could break other E2E test suites are modified.

Performance Test Selection:
The changes are limited to Price Alerts creation flow and Watchlist auto-add functionality. No performance-sensitive paths are affected — no asset loading loops, no rendering performance changes, no login/onboarding/launch flows, no swap flows. The changes add a single mutation call on price alert creation, which is not a performance-critical path covered by any available performance test tag.

View GitHub Actions results

@github-actions github-actions Bot added risk:low AI analysis: low risk and removed risk:medium AI analysis: medium risk labels Jul 30, 2026
@sonarqubecloud

Copy link
Copy Markdown

@juanmigdr
juanmigdr enabled auto-merge July 30, 2026 11:43
@juanmigdr
juanmigdr added this pull request to the merge queue Jul 30, 2026
Merged via the queue into main with commit e57db03 Jul 30, 2026
84 checks passed
@juanmigdr
juanmigdr deleted the feat/add-to-watchlist-on-alert-creation branch July 30, 2026 12:32
@github-actions github-actions Bot locked and limited conversation to collaborators Jul 30, 2026
@metamask-ci metamask-ci Bot added the release-8.6.0 Issue or pull request that will be included in release 8.6.0 label Jul 30, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

release-8.6.0 Issue or pull request that will be included in release 8.6.0 risk:low AI analysis: low risk size-M team-assets

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants