feat: add @metamask/profile-metrics-controller package with ProfileMetricsService

[mikesposito]

Explanation

The @metamask/profile-metrics-controller package is being added to the monorepo.

ProfileMetricsService is also being added to the package, to be used for sending requests to the Authentication API. The service will be consumed by ProfileMetricsController, which is being added in this follow-up PR: #7196

References

• Related to https://consensyssoftware.atlassian.net/browse/WPC-179

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed, highlighting breaking changes as necessary
• I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

---

Note

Adds new @metamask/profile-metrics-controller with a ProfileMetricsService for submitting metrics to the Auth API, plus tests and repo wiring.

• New Package: @metamask/profile-metrics-controller
  • Implements ProfileMetricsService with submitMetrics using AuthenticationController:getBearerToken and createServicePolicy (retry, degraded threshold, circuit breaker); environment-aware getAuthUrl.
  • Exposes messenger action ProfileMetricsService:submitMetrics; exports types and service.
  • Adds tests covering success, missing entropySourceId, degraded timing, retry limits, circuit break/open/restore.
  • Includes package scaffolding: package.json, jest.config.js, tsconfig*, typedoc.json, README, LICENSE, CHANGELOG.
• Monorepo Integration
  • Updates README.md package list and dependency graph to include profile_metrics_controller and its deps.
  • Adds ownership/team mappings in .github/CODEOWNERS and teams.json.
  • Adds TS project references in root tsconfig.json and tsconfig.build.json; updates yarn.lock.

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

[cryptodev-2s]

@mikesposito Do we plan to add a controller to this newly added package ?

[mikesposito]

@cryptodev-2s Yes, it is being added in this follow-up PR: #7196 (the controller consumes the service added here)

[mathieuartu]

Overall looks good, left a couple of comments re how we intertwine with @metamask/profile-sync-controller. LMK what you think 🙂

[mathieuartu]

Should we default to Env.PRD since AuthenticationController defaults to this value as well?

[mikesposito]

I'm a little conflicted about this one. True that it must be the same as AuthenticationController, but on the other hand, having Env.PRD as default and using that everywhere (including local env) doesn't feel right either.

[cursor]

Bug: Default environment inconsistent with AuthenticationController

The env parameter defaults to SDK.Env.DEV but AuthenticationController defaults to Env.PRD (production). This inconsistency means that when ProfileMetricsService is instantiated without an explicit env, it will send requests to the development API while using a bearer token obtained from AuthenticationController that's configured for production. This could cause authentication mismatches in production environments where env isn't explicitly set. The PR discussion specifically flagged this concern.

 

[cursor]

Bug: Environment default mismatch causes authentication failures

The env parameter defaults to SDK.Env.DEV, but AuthenticationController defaults to Env.PRD. When ProfileMetricsService is instantiated without explicitly specifying env, it will request bearer tokens from a production-configured AuthenticationController but attempt to use them against development API endpoints. This environment mismatch could cause authentication failures since tokens from one environment may not be valid for another. The PR discussion confirms this concern, with acknowledgment that "it must be the same as AuthenticationController."

 

[mathieuartu]

Looks good! Nice work!

[cryptodev-2s]

LGTM!