feat(rewards): expose GET /campaigns endpoint through RewardsController

[VGR-GIT]

Summary

• Adds CampaignType enum and CampaignDto / CampaignsState types matching the backend DTO from va-mmcx-rewards#469
• Implements getCampaigns(subscriptionId) in RewardsDataService calling GET /campaigns with subscription auth
• Implements getCampaigns(subscriptionId) in RewardsController with 5-minute cache via wrapWithCache and #withAuthRetry for 403 recovery
• Adds campaigns to controller state metadata/default state (persisted, usedInUi)
• Registers RewardsDataService:getCampaigns action in the rewards-controller messenger
• Updates initial-background-state.json and state-logs snapshot

Backend model (from va-mmcx-rewards#469)

CampaignDto {
  id: string
  type: CampaignType  // 'ONDO_HOLDING'
  name: string
  startDate: string
  endDate: string
  termsAndConditions: Json | null
  excludedRegions: string[]
  statusLabel: string
}

Test plan

• rewards-data-service.test.ts — 3 new getCampaigns tests: success (correct endpoint + auth headers), empty array, error response
• RewardsController.test.ts — 5 new getCampaigns tests: disabled flag, API fetch + cache write, cache hit (fresh), cache miss (stale), logging
• All 727 rewards controller tests passing
• Prettier and ESLint clean (no errors)

CHANGELOG entry: feat(rewards): expose GET /campaigns endpoint through RewardsController with 5-minute cache

🤖 Generated with Claude Code

---

Note

Medium Risk
Adds a new rewards API surface (getCampaigns) with caching and persisted controller/UI state, plus a new feature flag controlling behavior. Moderate risk due to new network path and state persistence/invalidation changes affecting rewards UI refresh timing.

Overview
Adds rewards campaigns support end-to-end. Introduces CampaignType/CampaignDto types, a new RewardsDataService:getCampaigns action that calls GET /campaigns, and a RewardsController:getCampaigns handler that caches results for 5 minutes and persists them in controller state.

Wires campaigns into the UI/store and tightens event invalidation. Adds campaigns fields/actions/selectors to the rewards reducer, a useRewardCampaigns hook (focus fetch + invalidation on account/balance events, gated by selectCampaignsRewardsEnabledFlag), and updates useInvalidateByRewardEvents + several rewards hooks to memoize their event lists and accept readonly event arrays to avoid unnecessary re-subscriptions. Tests and state snapshots/initial background state are updated accordingly.

^{Written by Cursor Bugbot for commit d31ef7d. This will update automatically on new commits. Configure here.}

[github-actions]

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.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: None (no tests recommended)
• Selected Performance tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 85%

click to see 🤖 AI reasoning details

E2E Test Selection:
This PR adds a new "Campaigns" feature to the existing Rewards system. The changes are:

1. Additive Controller Changes: New getCampaigns() method added to RewardsController with caching, new state property campaigns, and new action handler. No existing functionality is modified.

2. Feature Flag Gated: The new campaigns feature is controlled by rewardsCampaignsEnabled feature flag, meaning it won't affect users unless explicitly enabled.

3. No Existing E2E Tests: There are no E2E tests for the Rewards feature in the test suite (searched for rewards in *.feature and *.spec.js files - no matches found).

4. Isolated Feature: The Rewards system is a self-contained feature that doesn't directly impact core wallet functionality like transactions, accounts, networks, confirmations, or trading flows.

5. Minor Refactors: The changes to existing hooks (useActivePointsBoosts, usePointsEvents, useReferralDetails, useRewardOptinSummary, useSnapshots, useUnlockedRewards) are purely type safety improvements - wrapping event arrays in useMemo with as const to satisfy the updated readonly type requirement in useInvalidateByRewardEvents.

6. Comprehensive Unit Tests: The PR includes extensive unit tests for the new functionality (RewardsController.test.ts, rewardsEnabled.test.ts, useRewardCampaigns.test.ts, rewards-data-service.test.ts, selectors.test.ts).

Since there are no E2E tests for Rewards functionality and the changes are additive, feature-flag gated, and don't affect any core wallet flows covered by the available E2E test tags, no E2E tests need to be run.

Performance Test Selection:
The changes are to the Rewards feature which is a specialized feature that doesn't impact core app performance metrics. The new campaigns functionality is feature-flag gated and involves API calls with caching (5-minute TTL), which is standard async data fetching. The changes don't affect: app launch/startup, login flow, account list rendering, swap flows, asset loading, or any other performance-critical paths. The minor refactors to existing hooks (adding useMemo for event arrays) are micro-optimizations that won't have measurable performance impact. No performance tests are needed.

View GitHub Actions results

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[cursor]

Missing 403/401 AuthorizationFailedError in getCampaigns service

Medium Severity

The getCampaigns method checks !response.ok and throws a generic Error, but for a 401 response the makeRequest helper only auto-throws AuthorizationFailedError for 403. If the backend returns 401 (as it can for expired tokens), #withAuthRetry in the controller won't catch it for re-authentication, unlike getSubscriptionAccounts which explicitly handles 401 with AuthorizationFailedError.

 

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
97.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud