feat: add status tracking to RampsController ResourceState

[georgeweiler]

Explanation

Rehosting #8116

This PR adds explicit status tracking to the ResourceState type in @metamask/ramps-controller. Previously, the controller used only isLoading and error fields, making it impossible to distinguish between:

1. An uninitialized resource (never fetched)
2. A successfully fetched resource with no data

This ambiguity caused false positive "token unavailable" errors in MetaMask Mobile when payment methods were still loading.

Changes

RampsController.ts

• Added status: \${RequestStatus}`field toResourceState` type
• Updated createDefaultResourceState to initialize with status: RequestStatus.IDLE
• Added private #setResourceStatus method to update resource status
• Wired status transitions in executeRequest:
  • loading when fetch starts
  • success when fetch completes successfully
  • error when fetch fails

The status field uses the existing RequestStatus enum from RequestCache.ts ('idle' | 'loading' | 'success' | 'error'), already exported in the package's public API.

References

• Related mobile PR: fix: prevent false token unavailable errors with RampsController status tracking metamask-mobile#26962
• Original issue: Mobile false positive "token unavailable" with stale quotes

Checklist

• Tests pass
• Linter passes
• No breaking changes to existing controller consumers (status is optional via migration)

---

Note

Medium Risk
Adds a new status field to persisted/UI-exposed controller state and updates request/concurrency cleanup logic, which could affect consumers that rely on prior loading/error semantics. Includes new last-write-wins behavior for concurrent requests and region-change aborts, so subtle state-transition regressions are possible.

Overview
Adds status to ResourceState (using RequestStatus) and initializes it to idle across all controller resources, including Transak-native sub-resources.

Updates executeRequest to set resource status alongside isLoading (including concurrent-request ref counting and a terminal last-write-wins status when the final in-flight request completes), and ensures dependent-resource resets (e.g. region changes) also reset status. Transak helpers (transakGetUserDetails, transakGetBuyQuote, transakGetKycRequirement) now explicitly set loading/success/error status.

Tests and snapshots are updated/expanded to cover the new field and race/abort scenarios; widget URL fetching behavior is clarified via tests (undefined URL -> null, empty string preserved). Changelog notes the new status field.

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

[georgeweiler]

@cursoragent fix the changelog please.

[cursor]

Done! I've fixed the changelog issue. The problem was that the changelog entry was referencing the original PR #8116, but since this is a rehost, it needed to reference the current PR #8158.

I've updated the changelog entry to point to PR #8158 and verified that the changelog validation now passes. The change has been committed and pushed to the branch.

  

[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]

Stale concurrent request resets status to IDLE incorrectly

Medium Severity

The terminalStatus variable defaults to RequestStatus.IDLE. When concurrent requests target the same resource type and the last one to finish is stale (isResultCurrent returns false), terminalStatus remains IDLE and gets committed as the resource's status. This creates a state where data contains valid fetched results (from an earlier current request), error is null, isLoading is false, but status is 'idle' — implying "never fetched." This undermines the core goal of the PR: distinguishing between uninitialized and successfully-fetched-empty resources. A consumer checking status === 'idle' to detect "never fetched" could get a false positive even after a successful fetch.

 

[amitabh94]

Approving this but I believe that introduction of React query in mobile codebase would solve the issue where we manually try to track the status of requests .

I think card and predict teams are already using it and this is the direction codebase is generally moving towards.

It could be a broader change so it could be its own PR later but wanted to leave the comment here in order to build a case for that.

[georgeweiler]

@amitabh94 I like that approach better. I did a quick AI spike and it's feasible. I think we should close this PR and the mobile equivalent and do a react query approach instead.

PLAN.md

[amitabh94]

Should we get this in and then later upgrade it or do you feel we should straight away go to React query @georgeweiler ?

[georgeweiler]

I think we should close this. Here's a first-draft: MetaMask/metamask-mobile#27271