feat(27254): implement new remote-feature-flag-controller #4931

DDDDDanica · 2024-11-14T17:02:27Z

Explanation

Following the ADR here

Adds a new controller, remote-feature-flag-controller that fetches the remote feature flags and provide cache solution for consumers.

References

Related to #27254

Changelog

`@metamask/remote-feature-flag-controller`

ADDED: Initial release

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 highlighted breaking changes using the "BREAKING" category above as appropriate
I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

socket-security · 2024-11-15T03:14:48Z

No dependency changes detected. Learn more about Socket for GitHub ↗︎

👍 No dependency changes detected in pull request

DDDDDanica · 2024-11-20T12:33:44Z

@metamaskbot publish-preview

github-actions · 2024-11-20T12:37:22Z

Preview builds have been published. See these instructions for more information about preview builds.

Expand for full list of packages and versions.

{
  "@metamask-previews/accounts-controller": "19.0.0-preview-fcc71a0",
  "@metamask-previews/address-book-controller": "6.0.1-preview-fcc71a0",
  "@metamask-previews/announcement-controller": "7.0.1-preview-fcc71a0",
  "@metamask-previews/approval-controller": "7.1.1-preview-fcc71a0",
  "@metamask-previews/assets-controllers": "44.0.1-preview-fcc71a0",
  "@metamask-previews/base-controller": "7.0.2-preview-fcc71a0",
  "@metamask-previews/build-utils": "3.0.1-preview-fcc71a0",
  "@metamask-previews/chain-controller": "0.1.3-preview-fcc71a0",
  "@metamask-previews/composable-controller": "9.0.1-preview-fcc71a0",
  "@metamask-previews/controller-utils": "11.4.3-preview-fcc71a0",
  "@metamask-previews/ens-controller": "15.0.0-preview-fcc71a0",
  "@metamask-previews/eth-json-rpc-provider": "4.1.6-preview-fcc71a0",
  "@metamask-previews/gas-fee-controller": "22.0.1-preview-fcc71a0",
  "@metamask-previews/json-rpc-engine": "10.0.1-preview-fcc71a0",
  "@metamask-previews/json-rpc-middleware-stream": "8.0.5-preview-fcc71a0",
  "@metamask-previews/keyring-controller": "18.0.0-preview-fcc71a0",
  "@metamask-previews/logging-controller": "6.0.2-preview-fcc71a0",
  "@metamask-previews/message-manager": "11.0.1-preview-fcc71a0",
  "@metamask-previews/multichain": "0.0.0-preview-fcc71a0",
  "@metamask-previews/name-controller": "8.0.1-preview-fcc71a0",
  "@metamask-previews/network-controller": "22.0.2-preview-fcc71a0",
  "@metamask-previews/notification-controller": "7.0.0-preview-fcc71a0",
  "@metamask-previews/notification-services-controller": "0.13.0-preview-fcc71a0",
  "@metamask-previews/permission-controller": "11.0.3-preview-fcc71a0",
  "@metamask-previews/permission-log-controller": "3.0.1-preview-fcc71a0",
  "@metamask-previews/phishing-controller": "12.3.0-preview-fcc71a0",
  "@metamask-previews/polling-controller": "12.0.1-preview-fcc71a0",
  "@metamask-previews/preferences-controller": "14.0.0-preview-fcc71a0",
  "@metamask-previews/profile-sync-controller": "1.0.2-preview-fcc71a0",
  "@metamask-previews/queued-request-controller": "7.0.1-preview-fcc71a0",
  "@metamask-previews/rate-limit-controller": "6.0.1-preview-fcc71a0",
  "@metamask-previews/selected-network-controller": "19.0.0-preview-fcc71a0",
  "@metamask-previews/signature-controller": "22.0.0-preview-fcc71a0",
  "@metamask-previews/transaction-controller": "39.0.0-preview-fcc71a0",
  "@metamask-previews/user-operation-controller": "18.0.0-preview-fcc71a0"
}

danjm · 2024-11-26T04:28:58Z

packages/remote-feature-flag-controller/src/remote-feature-flag-controller.ts

+      return [];
+    }
+
+    if (this.#isCacheExpired()) {


Suggested change

if (this.#isCacheExpired()) {

if (!this.#isCacheExpired()) {

Because we only want to return the data cached in state if the cache is NOT expired

Good catch ! Since the variable name changed, the logic should be reversed. Modified in 276357d

danjm · 2024-11-26T04:30:26Z

packages/remote-feature-flag-controller/src/remote-feature-flag-controller.ts

+   * @private
+   */
+  #isCacheExpired(): boolean {
+    return Date.now() - this.state.cacheTimestamp < this.#fetchInterval;


Suggested change

return Date.now() - this.state.cacheTimestamp < this.#fetchInterval;

return Date.now() - this.state.cacheTimestamp > this.#fetchInterval;

Now that this is named isCacheExpired, it should return true when the cache is expired / no longer valid

Addressed 276357d

danjm · 2024-11-26T04:32:43Z

packages/remote-feature-flag-controller/src/remote-feature-flag-controller.ts

+        this.updateCache(flags.cachedData);
+        resolve(flags.cachedData);
+      }
+      return await promise;


If there is no cached data, or if there is an API error, it looks like this promise will stay unresolved forever

Should we have a catch here?

Agreed ! when there is no cached data, we should return []

The error catch is handled in service side, hence we don't need catch here, hope it makes sense !

return { error: true, message: err.message || 'Unknown error', statusCode: err.response?.status?.toString() || null, statusText: err.response?.statusText || null, cachedData: cachedData || [], cacheTimestamp: cacheTimestamp || Date.now(), };

Addressed 276357d

What was the reason for handling the error as is done in the service?

I notice that the example gas price service does not handle errors this way (https://github.com/MetaMask/core/blob/main/examples/example-controllers/src/gas-prices-service/gas-prices-service.ts#L62)

danjm

Everything looks good to me, except I have those last questions about the approach to error handling.

mcmire

Some more suggestions. After that I think we are good here.

mcmire · 2024-11-26T18:46:13Z

packages/remote-feature-flag-controller/src/remote-feature-flag-controller.test.ts

+) {
+  return new RemoteFeatureFlagController({
+    messenger: options.messenger ?? getControllerMessenger(),
+    state: options.state ?? { remoteFeatureFlags: [], cacheTimestamp: 0 },


Nit: Won't the controller mix in defaults for state already? So we should be able to simply say:

Suggested change

state: options.state ?? { remoteFeatureFlags: [], cacheTimestamp: 0 },

state: options.state,

Good suggestion ! Also simplified messenger, addressed in 41bb909

mcmire · 2024-11-26T19:03:47Z

packages/remote-feature-flag-controller/src/remote-feature-flag-controller.test.ts

+      ).toHaveBeenCalledTimes(1);
+    });
+
+    it('should not affect existing cache when toggling disabled state', async () => {


Hmm. Is this test verifying the behavior of getRemoteFeatureFlags? Or is it verifying the behavior of disable? If the latter, then I wonder if it would be better to move this test for the describe for disable. You also may be able to simplify it; if we just want to verify disable doesn't change state then we can prepopulate that state in the controller.

Since this is primarily testing the disable functionality, I'll move to a different test and simplify it , addressed in 614997a0e55603083347c47f9e04d74a2055db50

describe('disable', () => { it('should preserve cached flags but return empty array when disabled', async () => {

mcmire · 2024-11-26T19:20:01Z

packages/remote-feature-flag-controller/src/remote-feature-flag-controller.test.ts

+      expect(fetchSpy).toHaveBeenCalledTimes(1);
+
+      // Simulate cache expiration
+      controller.update((state) => ({


Hmm, this won't work; only the controller can update its own state — you can't do that in a test.

Can we mock the current time using jest.useFakeTimers() and then use jest.setSystemTime() to fake-advance time instead?

that's a much better approach! addressed in 41bb909

mcmire · 2024-11-26T19:23:16Z

...es/remote-feature-flag-controller/src/client-config-api-service/client-config-api-service.ts

+        this.#fetch(url, { cache: 'no-cache' }),
+      );
+
+      if (!response || !response.ok) {


Is the check for !response needed here? response should not be null or undefined (the type says so)

Suggested change

if (!response || !response.ok) {

if (!response.ok) {

addressed in 614997a

mcmire · 2024-11-26T19:23:48Z

...es/remote-feature-flag-controller/src/client-config-api-service/client-config-api-service.ts

+          statusCode: response?.status?.toString() || null,
+          statusText: response?.statusText || 'Error',


Are the ?. needed here? Are the || needed as well?

Suggested change

statusCode: response?.status?.toString() || null,

statusText: response?.statusText || 'Error',

statusCode: response.status.toString(),

statusText: response.statusText,

Agree, moved 614997a

mcmire · 2024-11-26T19:25:21Z

...es/remote-feature-flag-controller/src/client-config-api-service/client-config-api-service.ts

+        statusText: response.statusText || 'OK',
+        cachedData: data || [],


Is the || needed here? Also do we want to use ?? instead?

Suggested change

statusText: response.statusText || 'OK',

cachedData: data || [],

statusText: response.statusText,

cachedData: data ?? [],

thanks for the suggestion, added 614997a

mcmire · 2024-11-26T19:30:29Z

...mote-feature-flag-controller/src/client-config-api-service/client-config-api-service.test.ts

+const BASE_URL = 'https://client-config.api.cx.metamask.io/v1';
+
+describe('ClientConfigApiService', () => {
+  let mockFetch: jest.Mock;


Instead of setting variables up top, what are your thoughts on setting them in the tests themselves? As it is, these variables are shared across all tests and that could lead to intermittent failures or difficult to debug tests. It also forces the reader to look up to find data that could be getting implicitly set up here.

If we need to hide some setup code because it doesn't matter to a test, can we use a mock object builder function like the one we've added in remote-feature-flag-controller.test.ts?

See here for more related guidance: https://github.com/MetaMask/contributor-docs/blob/main/docs/testing/unit-testing.md#avoid-the-use-of-beforeeach

Thanks both, the mock builder is indeed better than leaving setup in beforeEach. Addressed in 614997a

mcmire · 2024-11-26T19:31:54Z

...mote-feature-flag-controller/src/client-config-api-service/client-config-api-service.test.ts

+    expect(result).toStrictEqual({
+      error: true,
+      message: 'Network error',
+      statusCode: '503',


This is an example of why moving setup data into tests is a good idea. The reason that the statusCode is 503 on this line is because it's set on line 23. That isn't immediately obvious just from reading this test in isolation. And if that line changes it breaks this test (or any other test that relies on it).

Makes total sense. It is definitely better to create a builder and pass in params for each test case 🙏🏻 Addressed in 614997a

mcmire · 2024-11-26T19:49:31Z

...es/remote-feature-flag-controller/src/client-config-api-service/client-config-api-service.ts

+      const err = error as Error & {
+        response?: { status: number; statusText: string };
+      };
+      return {
+        error: true,
+        message: err.message || 'Unknown error',
+        statusCode: err.response?.status?.toString() || null,
+        statusText: err.response?.statusText || null,
+        cachedData: cachedData || [],
+        cacheTimestamp: cacheTimestamp || Date.now(),
+      };


Technically, error can be anything, so it may not be an Error object.

This is very ugly, but what about this (note: hasProperty comes from @metamask/utils):

Suggested change

const err = error as Error & {

response?: { status: number; statusText: string };

};

return {

error: true,

message: err.message || 'Unknown error',

statusCode: err.response?.status?.toString() || null,

statusText: err.response?.statusText || null,

cachedData: cachedData || [],

cacheTimestamp: cacheTimestamp || Date.now(),

};

const message = error instanceof Error ? error.message : 'Unknown error';

const response =

error instanceof TypeError &&

hasProperty(error, 'response') &&

error.response !== null &&

error.response !== undefined &&

hasProperty(error.response, 'status') &&

typeof error.response.status === 'string' &&

hasProperty(error.response, 'statusText') &&

typeof error.response.statusText !== 'string'

? (error.response as { status: string; statusText: string })

: null;

return {

error: true,

message,

statusCode: response ? response.status.toString() : 'Unknown error',

statusText: response ? response.statusText : null,

cachedData: cachedData || [],

cacheTimestamp: cacheTimestamp || Date.now(),

};

mcmire · 2024-11-26T19:53:04Z

...es/remote-feature-flag-controller/src/client-config-api-service/client-config-api-service.ts

+
+  #policy: IPolicy;
+
+  #baseUrl = 'https://client-config.api.cx.metamask.io/v1';


Nit: Should this be a constant?

Good catch, added to a new constant file in 41bb909

Gudahtt · 2024-11-26T20:02:39Z

...es/remote-feature-flag-controller/src/client-config-api-service/client-config-api-service.ts

+        cacheTimestamp: Date.now(),
+      };
+    } catch (error) {
+      console.error('Feature flag API request failed:', error);


Generally we should avoid console.error in libraries. If we directly call console here, there is no way for the client to control logging.

This case is a good example; upon failure we already have a network failure in the dev console. Adding an additional log might clutter the dev console even further without adding any more detail.

For debug information, I'd recommend using this debug logger: https://github.com/MetaMask/utils/blob/main/src/logging.ts
It lets you add log statements that can be easily enabled in development, but which are hidden by default.

Gudahtt · 2024-11-26T20:18:13Z

...es/remote-feature-flag-controller/src/client-config-api-service/client-config-api-service.ts

+  message: string;
+  statusCode: string | null;
+  statusText: string | null;
+  cachedData: FeatureFlags;


Two questions:

It looks like cachedData is the only property here that is used. What are the other properties for?

Why is this called cachedData? Is there any non-cached data that this is differentiated from? It looks like this property contains the feature flag configuration.

DDDDDanica force-pushed the feature/27254-feature-flag-controller branch 6 times, most recently from 78af7f4 to cd93f7a Compare November 15, 2024 03:13

DDDDDanica force-pushed the feature/27254-feature-flag-controller branch from cd93f7a to 82f7997 Compare November 16, 2024 03:42

DDDDDanica self-assigned this Nov 16, 2024

DDDDDanica force-pushed the feature/27254-feature-flag-controller branch 2 times, most recently from 78ca22b to a7a3cf1 Compare November 19, 2024 11:53

DDDDDanica marked this pull request as ready for review November 19, 2024 23:04

DDDDDanica requested a review from a team as a code owner November 19, 2024 23:04

DDDDDanica force-pushed the feature/27254-feature-flag-controller branch 9 times, most recently from 0519340 to fcc71a0 Compare November 20, 2024 12:19

DDDDDanica force-pushed the feature/27254-feature-flag-controller branch 6 times, most recently from 153ebc9 to 0fab160 Compare November 21, 2024 21:20

DDDDDanica force-pushed the feature/27254-feature-flag-controller branch 4 times, most recently from a2d5828 to fe6c0a5 Compare November 26, 2024 01:48

feat(27254): refactor based on pr review

6e0f005

DDDDDanica force-pushed the feature/27254-feature-flag-controller branch from fe6c0a5 to 6e0f005 Compare November 26, 2024 04:14

danjm reviewed Nov 26, 2024

View reviewed changes

DDDDDanica force-pushed the feature/27254-feature-flag-controller branch 2 times, most recently from 977ddbf to 276357d Compare November 26, 2024 11:46

feat(27254): address feedback - round 2

b25f847

DDDDDanica force-pushed the feature/27254-feature-flag-controller branch from 276357d to b25f847 Compare November 26, 2024 12:18

danjm and others added 2 commits November 26, 2024 09:27

Add jsdoc comments to remote-feature-flag-controller.ts

a8d53f3

feat(27254): fix lint errors for test file

a09cd92

DDDDDanica force-pushed the feature/27254-feature-flag-controller branch from 7f893dc to a09cd92 Compare November 26, 2024 16:04

danjm requested changes Nov 26, 2024

View reviewed changes

joaoloureirop requested a review from a team November 26, 2024 19:27

joaoloureirop previously approved these changes Nov 26, 2024

View reviewed changes

mcmire reviewed Nov 26, 2024

View reviewed changes

Gudahtt reviewed Nov 26, 2024

View reviewed changes

DDDDDanica dismissed joaoloureirop’s stale review via 41bb909 November 27, 2024 00:39

DDDDDanica force-pushed the feature/27254-feature-flag-controller branch 5 times, most recently from c19b249 to f13e7b4 Compare November 27, 2024 17:03

feat(27254): code review round 3

6ea8e51

DDDDDanica force-pushed the feature/27254-feature-flag-controller branch from f13e7b4 to 6ea8e51 Compare November 27, 2024 17:14

	return Date.now() - this.state.cacheTimestamp < this.#fetchInterval;
	return Date.now() - this.state.cacheTimestamp > this.#fetchInterval;

	state: options.state ?? { remoteFeatureFlags: [], cacheTimestamp: 0 },
	state: options.state,

		statusCode: response?.status?.toString() \|\| null,
		statusText: response?.statusText \|\| 'Error',

		statusText: response.statusText \|\| 'OK',
		cachedData: data \|\| [],

-      const err = error as Error & {
-        response?: { status: number; statusText: string };
-      };
-      return {
-        error: true,
-        message: err.message || 'Unknown error',
-        statusCode: err.response?.status?.toString() || null,
-        statusText: err.response?.statusText || null,
-        cachedData: cachedData || [],
-        cacheTimestamp: cacheTimestamp || Date.now(),
-      };
+      const message = error instanceof Error ? error.message : 'Unknown error';
+      const response =
+        error instanceof TypeError &&
+        hasProperty(error, 'response') &&
+        error.response !== null &&
+        error.response !== undefined &&
+        hasProperty(error.response, 'status') &&
+        typeof error.response.status === 'string' &&
+        hasProperty(error.response, 'statusText') &&
+        typeof error.response.statusText !== 'string'
+          ? (error.response as { status: string; statusText: string })
+          : null;
+      return {
+        error: true,
+        message,
+        statusCode: response ? response.status.toString() : 'Unknown error',
+        statusText: response ? response.statusText : null,
+        cachedData: cachedData || [],
+        cacheTimestamp: cacheTimestamp || Date.now(),
+      };


		#policy: IPolicy;

		#baseUrl = 'https://client-config.api.cx.metamask.io/v1';

feat(27254): implement new remote-feature-flag-controller #4931

Are you sure you want to change the base?

feat(27254): implement new remote-feature-flag-controller #4931

Conversation

DDDDDanica commented Nov 14, 2024 • edited Loading

Explanation

References

Changelog

@metamask/remote-feature-flag-controller

Checklist

socket-security bot commented Nov 15, 2024 • edited Loading

DDDDDanica commented Nov 20, 2024

github-actions bot commented Nov 20, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danjm Nov 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danjm left a comment

Choose a reason for hiding this comment

mcmire left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DDDDDanica Nov 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DDDDDanica Nov 27, 2024 • edited Loading

Choose a reason for hiding this comment

mcmire Nov 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DDDDDanica commented Nov 14, 2024 •

edited

Loading

`@metamask/remote-feature-flag-controller`

socket-security bot commented Nov 15, 2024 •

edited

Loading

danjm Nov 26, 2024 •

edited

Loading

DDDDDanica Nov 27, 2024 •

edited

Loading

DDDDDanica Nov 27, 2024 •

edited

Loading

mcmire Nov 26, 2024 •

edited

Loading