[token-detection-controller] Refactor `detectTokens` method #3938

MajorLift · 2024-02-20T23:53:16Z

Explanation

Adds refactors and cosmetic, typing fixes to #3923.

Extracts three methods from TokenDetectionController's detectTokens method:
- #getCorrectChainIdAndNetworkClientId
- #getTokenListAndSlicesOfTokensToDetect
- #addDetectedTokens
Maintains distinction between class fields #selectedAddress, #networkClientId and corresponding parameters used in detectTokens and its helper methods, so that detectTokens method can be used independently of polling/passive detection.
Refactor #getCorrectChainIdAndNetworkClientId to remove findNetworkClientIdByChainId which might return inconsistent/unexpected results, and replace it with getState, getNetworkClientById
Add missing method return types
Type networkClientId as NetworkClientId
Fix excess properties from legacy token list, define LegacyToken, TokenDetectionMap
Removes #chainId class field.

References

Closes TokenDetectionController: Refactor #1614
Fixes [token-detection-controller] Remove limit on number of tokens that can be detected #3661
Blocked by (Follows from) [token-detection-controller] Apply recent DetectTokensController updates #3923
Blocking Bring TokenDetectionController up-to-date and release new version of assets-controllers #3916
Blocking Release 118.0.0 #3918

Changelog

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

MajorLift · 2024-02-22T00:55:10Z

packages/assets-controllers/src/TokenDetectionController.ts

+  #chainIdAgainstWhichToDetect: Hex;
+
+  #addressAgainstWhichToDetect: string;
+
+  #networkClientIdAgainstWhichToDetect: NetworkClientId;


Should these be maintained separately from #chainId, #selectedAddress, #networkClientId? My assumption is that we want the detectTokens method to be callable independently of the polling/passive detection performed by the controller and messenger. At least, that seems to be what the current implementation's avoidance of class fields in detectTokens suggests.

You're right that consumers should be able to call detectTokens independently, and it should just work.

It makes sense that we would cache the currently selected network as well as the currently selected account. I don't think we need to cache the chain ID, because we can always ask the network client. (But removing that is for another PR.)

As for these three variables, though, it seems to me that we've created them so that we can break up detectTokens into pieces. But, why not pass along these values, then? It seems that this would make it easier for someone to read the code because there would be fewer things for them to track.

Agree that a pure style that avoids using class fields might be more readable here.

Removed the three unnecessary class fields here: ab0e3eb (#3938)

Also removed #chainId: 12ba664 (#3938)

MajorLift · 2024-02-22T00:56:48Z

packages/assets-controllers/src/TokenDetectionController.ts

-  Token,
-  'aggregators' | 'image' | 'balanceError' | 'isERC721'
-> & {
+type LegacyToken = {
  name: string;
-  logo: string;
+  logo: `${string}.svg`;
+  symbol: string;
+  decimals: number;
  erc20?: boolean;
  erc721?: boolean;
 };

+type TokenDetectionMap = {
+  [P in keyof TokenListMap]: Omit<TokenListMap[P], 'occurrences'>;
+};
+
 export const STATIC_MAINNET_TOKEN_LIST = Object.entries<LegacyToken>(
  contractMap,
-).reduce<
-  Record<
-    string,
-    Partial<TokenListToken> & Pick<Token, 'address' | 'symbol' | 'decimals'>
-  >
->((acc, [base, contract]) => {
-  const { logo, ...tokenMetadata } = contract;


Better typing and handling of legacy token list.

MajorLift · 2024-02-23T18:22:09Z

packages/assets-controllers/src/TokenDetectionController.ts

+    await safelyExecute(async () => {
+      const balances = await this.#getBalancesInSingleCall(
+        this.#addressAgainstWhichToDetect,
+        tokensSlice,
+        this.#networkClientIdAgainstWhichToDetect,
+      );
+
+      const tokensWithBalance: Token[] = [];
+      const eventTokensDetails: string[] = [];
+      for (const nonZeroTokenAddress of Object.keys(balances)) {
+        const { decimals, symbol, aggregators, iconUrl, name } =
+          this.#tokenList[nonZeroTokenAddress];
+        eventTokensDetails.push(`${symbol} - ${nonZeroTokenAddress}`);
+        tokensWithBalance.push({
+          address: nonZeroTokenAddress,
+          decimals,
+          symbol,
+          aggregators,
+          image: iconUrl,
+          isERC721: false,
+          name,
+        });
      }

-      await safelyExecute(async () => {
-        const balances = await this.#getBalancesInSingleCall(
-          addressAgainstWhichToDetect,
-          tokensSlice,
-          networkClientIdAgainstWhichToDetect,
+      if (tokensWithBalance.length) {
+        this.#trackMetaMetricsEvent({
+          event: 'Token Detected',
+          category: 'Wallet',
+          properties: {
+            tokens: eventTokensDetails,
+            token_standard: 'ERC20',
+            asset_type: 'TOKEN',
+          },
+        });
+
+        await this.messagingSystem.call(
+          'TokensController:addDetectedTokens',
+          tokensWithBalance,
+          {
+            selectedAddress: this.#addressAgainstWhichToDetect,
+            chainId: this.#chainIdAgainstWhichToDetect,
+          },
        );
-        const tokensWithBalance: Token[] = [];
-        const eventTokensDetails: string[] = [];
-        for (const nonZeroTokenAddress of Object.keys(balances)) {
-          const { decimals, symbol, aggregators, iconUrl, name } =
-            tokenListUsed[nonZeroTokenAddress];
-          eventTokensDetails.push(`${symbol} - ${nonZeroTokenAddress}`);
-          tokensWithBalance.push({
-            address: nonZeroTokenAddress,
-            decimals,
-            symbol,
-            aggregators,
-            image: iconUrl,
-            isERC721: false,
-            name,
-          });
-        }
-        if (tokensWithBalance.length) {
-          this.#trackMetaMetricsEvent({
-            event: 'Token Detected',
-            category: 'Wallet',
-            properties: {
-              tokens: eventTokensDetails,
-              token_standard: 'ERC20',
-              asset_type: 'TOKEN',
-            },
-          });
-          await this.messagingSystem.call(
-            'TokensController:addDetectedTokens',
-            tokensWithBalance,
-            {
-              selectedAddress: addressAgainstWhichToDetect,
-              chainId: chainIdAgainstWhichToDetect,
-            },
-          );
-        }
-      });
-    }
+      }
+    });


Large diff, but no actual changes here other than being moved to the new #addDetectedTokens method, and variable name updates (this.#{address,networkClientId,chainId}AgainstWhichToDetect, this.#tokenList).

packages/assets-controllers/src/TokenDetectionController.ts

MajorLift · 2024-02-26T18:21:26Z

packages/assets-controllers/src/TokenDetectionController.ts

+    const { selectedNetworkClientId } = this.messagingSystem.call(
+      'NetworkController:getState',
    );
-    const newNetworkClientId = this.messagingSystem.call(
-      'NetworkController:findNetworkClientIdByChainId',
-      chainId,
+    const {
+      configuration: { chainId },
+    } = this.messagingSystem.call(
+      'NetworkController:getNetworkClientById',
+      selectedNetworkClientId,
    );
    return {
      chainId,
-      networkClientId: newNetworkClientId,
+      networkClientId: selectedNetworkClientId,


Replaces getProviderConfig, findNetworkClientIdByChainId actions with getState, getNetworkClientById

I used getNetworkClientById instead of getNetworkConfigurationByNetworkClientId to avoid having to use this.#chainId as a fallback value for the case where the returned network configuration is undefined.

@bergeron @jiexi @adonesky1 Thoughts on this approach for retrieving networkClientId, chainId? c75fb3b

That approach looks okay to me, but wondering if you could get both in 1 call:

const { selectedNetworkClientId, providerConfig: { chainId }, } = this.messagingSystem.call('NetworkController:getState');

Looks good to me as long as there's no edge case where the selected network client's chainId is inconsistent with providerConfig. @mcmire What do you think?

Applied here: d6caee2

That makes sense. We might as well do the same thing for lines 418-428, huh?

I'm a little confused by that section. For detectTokens to work independently of the class state, shouldn't the user be able to pass in a network client ID that's not the currently selected network's and get the corresponding chain ID?

It seems like 418-428 is handling this case where the user-supplied network client ID is the source of truth, instead of the selectedNetworkClientId in NetworkState.

Otherwise, if the only network client ID ever used in detectTokens is the selectedNetworkClientId from NetworkState, shouldn't we remove the networkClientId params from detectTokens, restartTokenDetection, and getCorrect...?

Oh, sorry. What I meant was that it looks like further up we are using getNetworkConfigurationByNetworkClientId to get the configuration for the given network client, then we are checking to see whether we have a configuration, then we are getting the chain ID from the configuration. But in your changes here you are using getNetworkClientById. So do we want to be consistent? I'm thinking this:

#getCorrectChainIdAndNetworkClientId(networkClientId?: NetworkClientId): { chainId: Hex; networkClientId: NetworkClientId; } { if (networkClientId) { const { configuration: { chainId }, } = this.messagingSystem.call( 'NetworkController:getNetworkClientById', networkClientId, ); return { chainId, networkClientId, }; } const { selectedNetworkClientId } = this.messagingSystem.call( 'NetworkController:getState', ); const { configuration: { chainId }, } = this.messagingSystem.call( 'NetworkController:getNetworkClientById', selectedNetworkClientId, ); return { chainId, networkClientId: selectedNetworkClientId, }; }

And if we can do this, then we can flip it around:

#getCorrectChainIdAndNetworkClientId(givenNetworkClientId?: NetworkClientId): { chainId: Hex; networkClientId: NetworkClientId; } { const networkClientId = givenNetworkClientId ?? this.messagingSystem.call( 'NetworkController:getState', ).selectedNetworkClientId; const { configuration: { chainId }, } = this.messagingSystem.call( 'NetworkController:getNetworkClientById', networkClientId, ); return { chainId, networkClientId }; }

The reason I made that distinction was that getNetworkConfigurationByNetworkClientId returns undefined if there's no network configuration for the given network client ID.

So by using that first instead of getNetworkClientById (which never returns undefined), I thought we'd be able to rule out any user-supplied networkClientId that's not registered in the network state. If that's the case, we default to the selected network client ID.

But if that's not a meaningful edge case then the second option looks good I can apply it rn.

Oh I see what you're saying. Okay, that makes sense!

…dates (#3923) ## Explanation As a preparatory step for fully replacing the extension `DetectTokensController` with the consolidated core repo `TokenDetectionController`, `TokenDetectionController` needs to be updated with changes made to the extension `DetectTokensController` since #1813 was closed. #### Diff of `DetectTokensController` state - [MetaMask/metamask-extension@`5d285f7be5f7be981995dfa725aad97d81cc990a..85cd1c89039e900b452edb704ec37e9ccbd3e76a`#diff-323d0cf464](https://github.com/MetaMask/metamask-extension/compare/5d285f7be5f7be981995dfa725aad97d81cc990a..85cd1c89039e900b452edb704ec37e9ccbd3e76a#diff-323d0cf46498be3850b971474905354ea5ccf7fa13745ad1e6eba59c5b586830) ### Differences from extension `DetectTokensController` - Refactors logic for retrieving `chainId`, `networkClientId` into `this.#getCorrectChainIdAndNetworkClientId` - Uses `getNetworkConfigurationByNetworkClientId` action instead of `getNetworkClientById` to retrieve `chainId`. - If `networkClientId` is not supplied to the method, or it's supplied but `getNetworkConfigurationByNetworkClientId` returns `undefined`, finds `chainId` from `providerConfig`. - `detectTokens` replaces `detectNewTokens` - `detectTokens` accepts options object `{ selectedAddress, networkClientId }` instead of `{ selectedAddress, chainId, networkClientId }`. - Does not throw error if `getBalancesInSingleCall` fails. Also does not exit early -- continues looping. - Passes lists of full `Token` types to `TokensController:addDetectedTokens` instead of objects containing only `{ address, decimals, symbol }`. - `#trackMetaMetricsEvents` is a private method instead of protected. - Passes string literals instead of extension shared constants into `_trackMetaMetricsEvent`. ## References - Partially implements #3916 - Blocking #3918 - Changes adopted from: - MetaMask/metamask-extension#22898 - MetaMask/metamask-extension#22814 - #3914 - MetaMask/metamask-extension#21437 - Blocking (Followed by) #3938 ## Changelog ### [`@metamask/assets-controllers`](https://github.com/MetaMask/core/pull/3923/files#diff-ee47d03d53776b8dd530799a8047f5e32e36e35765620aeb50b294adc3339fab) ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've highlighted breaking changes using the "BREAKING" category above as appropriate --------- Co-authored-by: jiexi <jiexiluan@gmail.com>

…IdAndNetworkClientId`, `#getTokenListAndSlicesOfTokensToDetect`, `#addDetectedTokens` - Fixes #1614 - Maintains distinction between private class fields `#{chainId,selectedAddress,networkClientId}{,AgainstWhichToDetect}`, so that `detectTokens` method can be used independently of polling/passive detection (convert to static method?). Is this expected behavior?

…yChainId` actions with `getState`, `getNetworkClientById`

packages/assets-controllers/src/TokenDetectionController.ts

- Fixes #3661 Co-authored-by: Brian Bergeron <brian.e.bergeron@gmail.com>

packages/assets-controllers/src/TokenDetectionController.ts

mcmire

Makes sense overall, but I had some comments.

packages/assets-controllers/CHANGELOG.md

mcmire · 2024-03-01T04:02:40Z

packages/assets-controllers/src/TokenDetectionController.test.ts

  NetworkClientId,
 } from '@metamask/network-controller';
 import { defaultState as defaultNetworkState } from '@metamask/network-controller';
+import type { AutoManagedNetworkClient } from '@metamask/network-controller/src/create-auto-managed-network-client';


Heads up: #3998 will make it impossible to import subpaths, so this will need to be changed when that happens, but is okay for now.

Yes I was surprised to learn that AutoManagedNetworkClient isn't a package-level export. Is this an intentional choice? Otherwise I could create a ticket for exporting this.

It wasn't. I don't think I expected anyone to have to use this type, as it's low-level. But there's no harm in exporting it or anything.

mcmire · 2024-03-01T23:38:11Z

packages/assets-controllers/src/TokenDetectionController.ts

+  #chainIdAgainstWhichToDetect: Hex;
+
+  #addressAgainstWhichToDetect: string;
+
+  #networkClientIdAgainstWhichToDetect: NetworkClientId;


You're right that consumers should be able to call detectTokens independently, and it should just work.

It makes sense that we would cache the currently selected network as well as the currently selected account. I don't think we need to cache the chain ID, because we can always ask the network client. (But removing that is for another PR.)

As for these three variables, though, it seems to me that we've created them so that we can break up detectTokens into pieces. But, why not pass along these values, then? It seems that this would make it easier for someone to read the code because there would be fewer things for them to track.

mcmire · 2024-03-01T23:46:51Z

packages/assets-controllers/src/TokenDetectionController.ts

-    const { chainId } =
+    this.#addressAgainstWhichToDetect = this.#selectedAddress;
+
+    const { chainId, networkClientId: correctNetworkClientId } =
      this.#getCorrectChainIdAndNetworkClientId(networkClientId);


With your changes to #getCorrectChainIdAndNetworkClientId, it will retrieve the currently selected network from NetworkController. So does the constructor need to take a networkClientId? It seems like we don't need to pass it here.

Hmm looks like this is also related to #3938 (comment). If we allow #getCorrectChainIdAndNetworkClientId to accept a non-selected network client id and then return its chain id, then keeping the networkClientId constructor option would also allow token-detection-controller's internal state to diverge from network-controller's.

Removing this will be fairly disruptive for the tests, but it looks like it'll be necessary.

Applied here: d0f6f69 (#3938)

mcmire · 2024-03-01T23:47:48Z

packages/assets-controllers/src/TokenDetectionController.ts

+    const { selectedNetworkClientId } = this.messagingSystem.call(
+      'NetworkController:getState',
    );
-    const newNetworkClientId = this.messagingSystem.call(
-      'NetworkController:findNetworkClientIdByChainId',
-      chainId,
+    const {
+      configuration: { chainId },
+    } = this.messagingSystem.call(
+      'NetworkController:getNetworkClientById',
+      selectedNetworkClientId,
    );
    return {
      chainId,
-      networkClientId: newNetworkClientId,
+      networkClientId: selectedNetworkClientId,


That makes sense. We might as well do the same thing for lines 418-428, huh?

Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>

… class field is always initialized with `selectedNetworkClientId` property of network-controller state

…gainstWhichToDetect` with input params

mcmire

This looks good to me!

…-refactor

* origin/main: refactor(controller-utils): replace `any` with types for type safety (#3975) Release 123.0.0 (#4007) [token-detection-controller] Refactor `detectTokens` method (#3938) fix: update usage of OP goerli to OP Sepolia (#3999)

MajorLift requested a review from a team as a code owner February 20, 2024 23:53

MajorLift changed the title ~~Add missing method return types~~ [token-detection-controller] Refactor detectTokens method Feb 20, 2024

MajorLift changed the base branch from main to 240215-TokenDetectionController-sync-with-extension February 20, 2024 23:53

MajorLift force-pushed the 240216-TokenDetectionController-detectTokens-refactor branch 2 times, most recently from 0aed206 to 6fc4688 Compare February 20, 2024 23:57

MajorLift mentioned this pull request Feb 20, 2024

[token-detection-controller] Apply recent DetectTokensController updates #3923

Merged

3 tasks

MajorLift force-pushed the 240215-TokenDetectionController-sync-with-extension branch from a955a1c to d4581a9 Compare February 21, 2024 00:17

MajorLift force-pushed the 240216-TokenDetectionController-detectTokens-refactor branch from 6fc4688 to f2faf4f Compare February 21, 2024 00:18

MajorLift force-pushed the 240215-TokenDetectionController-sync-with-extension branch from 8aaeb9c to aee4d13 Compare February 21, 2024 00:41

MajorLift force-pushed the 240216-TokenDetectionController-detectTokens-refactor branch from 4fdd841 to 5fee94d Compare February 21, 2024 00:42

MajorLift force-pushed the 240215-TokenDetectionController-sync-with-extension branch from aee4d13 to cf2d53f Compare February 21, 2024 00:46

MajorLift force-pushed the 240216-TokenDetectionController-detectTokens-refactor branch from 5fee94d to c91ff00 Compare February 21, 2024 00:48

MajorLift self-assigned this Feb 21, 2024

MajorLift added the team-wallet-framework label Feb 21, 2024

MajorLift commented Feb 22, 2024

View reviewed changes

MajorLift commented Feb 23, 2024

View reviewed changes

packages/assets-controllers/src/TokenDetectionController.ts Outdated Show resolved Hide resolved

MajorLift force-pushed the 240215-TokenDetectionController-sync-with-extension branch 2 times, most recently from 8a73dde to e9bbf1d Compare February 23, 2024 19:04

MajorLift force-pushed the 240216-TokenDetectionController-detectTokens-refactor branch 2 times, most recently from 606211e to 70f1a26 Compare February 26, 2024 17:32

MajorLift commented Feb 26, 2024

View reviewed changes

MajorLift requested review from jiexi, bergeron and adonesky1 February 26, 2024 20:52

Base automatically changed from 240215-TokenDetectionController-sync-with-extension to main February 27, 2024 00:13

MajorLift added 2 commits February 26, 2024 19:20

Add missing method return types

6916333

Type networkClientId as NetworkClientId

18134a5

MajorLift added 8 commits February 26, 2024 19:20

Consolidate tokenList, tokenListUsed variables

52f72f4

Fix typing, excess properties from legacy token list

0ad0629

[detectTokens] Extract tokenList into class field

5974b85

test: adjust coverage thresholds

99f1cff

Replace network-controller getProviderConfig, `findNetworkClientIdB…

d6caee2

…yChainId` actions with `getState`, `getNetworkClientById`

Update changelog

cad9b3b

Linter fixes

a09fcda

MajorLift force-pushed the 240216-TokenDetectionController-detectTokens-refactor branch from 70f1a26 to a09fcda Compare February 27, 2024 00:20

bergeron reviewed Feb 27, 2024

View reviewed changes

packages/assets-controllers/src/TokenDetectionController.ts Outdated Show resolved Hide resolved

Enable detection of arbitrary number of tokens in batches of 1000

f060ced

- Fixes #3661 Co-authored-by: Brian Bergeron <brian.e.bergeron@gmail.com>

MajorLift force-pushed the 240216-TokenDetectionController-detectTokens-refactor branch from f5c3194 to f060ced Compare February 27, 2024 16:00

MajorLift mentioned this pull request Feb 27, 2024

TokenDetectionController: Write comprehensive unit tests #1615

Open

bergeron reviewed Feb 27, 2024

View reviewed changes

packages/assets-controllers/src/TokenDetectionController.ts Outdated Show resolved Hide resolved

Remove unnecessary early exit condition

87b8f6a

bergeron previously approved these changes Feb 27, 2024

View reviewed changes

MajorLift mentioned this pull request Mar 1, 2024

Release 123.0.0 #4007

Merged

mcmire reviewed Mar 1, 2024

View reviewed changes

MajorLift dismissed bergeron’s stale review via 5bbc5a2 March 2, 2024 01:44

MajorLift and others added 4 commits March 1, 2024 17:44

Update packages/assets-controllers/CHANGELOG.md

5bbc5a2

Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>

Remove networkClientId from constructor options. #networkClientId…

d0f6f69

… class field is always initialized with `selectedNetworkClientId` property of network-controller state

Replace unnecessary class fields `#{chainId,address,networkClientId}A…

ab0e3eb

…gainstWhichToDetect` with input params

Remove unnecessary class field #chainId

12ba664

mcmire approved these changes Mar 4, 2024

View reviewed changes

Merge branch 'main' into 240216-TokenDetectionController-detectTokens…

59da8a6

…-refactor

MajorLift merged commit 34bf8f0 into main Mar 4, 2024
139 checks passed

MajorLift deleted the 240216-TokenDetectionController-detectTokens-refactor branch March 4, 2024 17:21

MajorLift restored the 240216-TokenDetectionController-detectTokens-refactor branch March 4, 2024 18:29

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[token-detection-controller] Refactor `detectTokens` method #3938

[token-detection-controller] Refactor `detectTokens` method #3938

MajorLift commented Feb 20, 2024 •

edited

Loading

MajorLift Feb 22, 2024 •

edited

Loading

mcmire Mar 1, 2024 •

edited

Loading

MajorLift Mar 2, 2024

MajorLift Mar 2, 2024 •

edited

Loading

MajorLift Mar 2, 2024

MajorLift Feb 22, 2024

MajorLift Feb 23, 2024 •

edited

Loading

MajorLift Feb 26, 2024

MajorLift Feb 26, 2024

bergeron Feb 27, 2024

MajorLift Feb 27, 2024

MajorLift Mar 1, 2024

mcmire Mar 1, 2024

MajorLift Mar 2, 2024 •

edited

Loading

mcmire Mar 4, 2024 •

edited

Loading

MajorLift Mar 4, 2024 •

edited

Loading

mcmire Mar 4, 2024

mcmire left a comment

mcmire Mar 1, 2024

MajorLift Mar 2, 2024 •

edited

Loading

mcmire Mar 4, 2024

mcmire Mar 1, 2024 •

edited

Loading

mcmire Mar 1, 2024

MajorLift Mar 2, 2024

MajorLift Mar 2, 2024

mcmire Mar 1, 2024

mcmire left a comment

[token-detection-controller] Refactor detectTokens method #3938

[token-detection-controller] Refactor detectTokens method #3938

Conversation

MajorLift commented Feb 20, 2024 • edited Loading

Explanation

References

Changelog

Checklist

MajorLift Feb 22, 2024 • edited Loading

Choose a reason for hiding this comment

mcmire Mar 1, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MajorLift Mar 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MajorLift Feb 23, 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

MajorLift Mar 2, 2024 • edited Loading

Choose a reason for hiding this comment

mcmire Mar 4, 2024 • edited Loading

Choose a reason for hiding this comment

MajorLift Mar 4, 2024 • edited Loading

Choose a reason for hiding this 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

MajorLift Mar 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mcmire Mar 1, 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

mcmire left a comment

Choose a reason for hiding this comment

[token-detection-controller] Refactor `detectTokens` method #3938

[token-detection-controller] Refactor `detectTokens` method #3938

MajorLift commented Feb 20, 2024 •

edited

Loading

MajorLift Feb 22, 2024 •

edited

Loading

mcmire Mar 1, 2024 •

edited

Loading

MajorLift Mar 2, 2024 •

edited

Loading

MajorLift Feb 23, 2024 •

edited

Loading

MajorLift Mar 2, 2024 •

edited

Loading

mcmire Mar 4, 2024 •

edited

Loading

MajorLift Mar 4, 2024 •

edited

Loading

MajorLift Mar 2, 2024 •

edited

Loading

mcmire Mar 1, 2024 •

edited

Loading