Skip to content

feat: Add Snap export handler usage tracking #3281

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

david0xd
Copy link
Contributor

@david0xd david0xd commented Mar 31, 2025

This PR moves MetaMetrics tracking of Snap export usage to Snap Controller.

Related issue: #3259

Extension integration PR: MetaMask/metamask-extension#31553
Mobile integration PR: MetaMask/metamask-mobile#14428

@david0xd david0xd self-assigned this Mar 31, 2025
david0xd added 2 commits April 8, 2025 12:03
Use registry for metadata

Replace controller with hook approach

Fix broken unit tests

Add unit tests
@david0xd david0xd force-pushed the dd/add-handler-tracking branch from 0683058 to 8bd8e34 Compare April 8, 2025 10:06
Copy link

codecov bot commented Apr 8, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.80%. Comparing base (88142f9) to head (a28d1d7).
Report is 11 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3281      +/-   ##
==========================================
+ Coverage   94.73%   97.80%   +3.07%     
==========================================
  Files         518      364     -154     
  Lines       11947     9940    -2007     
  Branches     1836     1622     -214     
==========================================
- Hits        11318     9722    -1596     
+ Misses        629      218     -411     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@david0xd david0xd marked this pull request as ready for review April 8, 2025 10:17
@david0xd david0xd requested a review from a team as a code owner April 8, 2025 10:17
@@ -1025,6 +1046,25 @@ export class SnapController extends BaseController<
Object.values(this.state?.snaps ?? {}).forEach((snap) =>
this.#setupRuntime(snap.id),
);

this.#trackSnapExport = throttleTracking(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should check with Christian if we want to track exports for preinstalled Snaps too

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain what would be the difference here? Why aren't they tracked with this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For other metrics, we don't always track preinstalled Snaps because they have a lot of usage and spam the metrics a bit.

E.g. https://github.com/MetaMask/metamask-extension/blob/main/app/scripts/metamask-controller.js#L3048

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes sense to skip it then. Added some logic to skip tracking of preinstalled Snaps.

async #getMetadata(snapId: string): Promise<SnapsRegistryMetadata | null> {
const database = await this.#getDatabase();
return database?.verifiedSnaps[snapId]?.metadata ?? null;
#getMetadata(snapId: string): SnapsRegistryMetadata | null {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically this is a breaking change, but I don't think we use this anywhere?

cc @Mrtenz

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't seem to be used anywhere in the extension outside of the SnapController at least, but like you said it's still a breaking change technically. If we want to avoid breaking it, we could keep the function async for now, and pair removing it with another breaking change in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't found use case for this method anywhere so far 🤔
And it is working this way because we have update called at first.
Screenshot 2025-04-10 at 15 26 45
So the snap_category is available and taken from the cached registry metadata.

PS. this is done because we wanted to avoid having async inside tracking.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO not worth it to keep it async, we don't want the performance hit of potentially updating the registry just for analytics

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean keeping the function signature the same, but returning the result without fetching it asynchronously.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

origin,
];

if (!previousCalls.has(key) || now - lastCall >= timeout) {
Copy link
Member

@FrederikBolding FrederikBolding Apr 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (!previousCalls.has(key) || now - lastCall >= timeout) {
if (now - lastCall >= timeout) {

I don't think we need the extra condition since we have a default for lastCall

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

Comment on lines 2959 to 3002
async getRegistryMetadata(
snapId: SnapId,
): Promise<SnapsRegistryMetadata | null> {
getRegistryMetadata(snapId: SnapId): SnapsRegistryMetadata | null {
this.#assertCanUsePlatform();
return await this.messagingSystem.call('SnapsRegistry:getMetadata', snapId);
return this.messagingSystem.call('SnapsRegistry:getMetadata', snapId);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly this function should probably be deleted, I have no idea why you would want to call SnapController:getRegistryMetadata when you can just use the registry directly

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know, probably I saw it exist and wanted to be consistent in some way. But, it's probably redundant.

Updated now with direct call to SnapsRegistry:getMetadata, and also removed getRegistryMetadata function.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I don't mean why you specifically would do it for this PR. I mean why would anyone call this function that we expose 😂

@david0xd david0xd changed the title Add Snap export handler usage tracking feat: Add Snap export handler usage tracking Apr 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants