Skip to content

Commit 2dc83be

Browse files
hmalik88Akaryatrh
authored andcommitted
feat: update provider type (#352)
* What is the current state of things and why does it need to change? There should be an easy way to identify the type of provider. Account discovery isn't limited to one group index, the discovery method should be looping through indices and provide said index to `createAccounts` * What is the solution your changes offer and how does it work? Add `providerType` property, add `AccountProviderType` enum and remove `groupIndex` from `discoverAndCreateAccounts`. ```gherkin Feature: Account Provider Type Management As a MetaMask developer I want to properly identify and manage different account provider types So that account discovery can work efficiently across multiple blockchain networks Background: Given the MetaMask accounts system is initialized And the AccountProviderType enum is available @provider-type @enum Scenario: AccountProviderType enum contains all supported provider types Given the AccountProviderType enum is defined When I check the available provider types Then I should see the following provider types: | Provider Type | | Evm | | Solana | | Btc | And each provider type should be a valid enum value And no additional provider types should be present @provider-type @Validation Scenario: Provider type property accepts only valid AccountProviderType values Given I have an account provider instance When I set the providerType to "Evm" Then the providerType should be set to AccountProviderType.Evm And the provider should be valid @provider-type @Validation @error-handling Scenario: Provider type property rejects invalid values Given I have an account provider instance When I attempt to set the providerType to an invalid value "InvalidType" Then the system should reject the invalid provider type And an appropriate error should be thrown And the provider should remain in a valid state @provider-type @evm Scenario: EVM provider has correct provider type Given I create an EVM account provider When I check the provider type Then the providerType should be AccountProviderType.Evm And the provider should support EVM-specific operations And the provider should be identifiable as an EVM provider @provider-type @Solana Scenario: Solana provider has correct provider type Given I create a Solana account provider When I check the provider type Then the providerType should be AccountProviderType.Solana And the provider should support Solana-specific operations And the provider should be identifiable as a Solana provider @provider-type @btc @future-proofing Scenario: BTC provider type is available for future implementation Given the AccountProviderType enum includes Btc When I reference AccountProviderType.Btc Then the Btc provider type should be available And it should be ready for future BTC provider implementation And it should not cause any runtime errors @account-discovery @provider-identification Scenario: Account discovery can identify provider types during discovery Given I have multiple account providers: | Provider Type | Status | | Evm | Active | | Solana | Active | | Btc | Inactive | When I perform account discovery Then the discovery process should identify each provider by its type And EVM accounts should be discovered using the Evm provider And Solana accounts should be discovered using the Solana provider And BTC provider should be skipped if inactive @account-discovery @group-index-removal Scenario: Account discovery works without groupIndex requirement Given I have an account provider with providerType set And the discoverAndCreateAccounts method is available When I call discoverAndCreateAccounts without providing groupIndex Then the method should execute successfully And accounts should be discovered across multiple indices And no groupIndex parameter should be required @account-discovery @multiple-indices Scenario: Account discovery loops through multiple indices Given I have an EVM account provider And there are accounts at indices 0, 1, and 2 When I call discoverAndCreateAccounts Then the discovery should check index 0 And the discovery should check index 1 And the discovery should check index 2 And all discovered accounts should be created And the discovery should continue until no more accounts are found @provider-type @service-integration Scenario: Service can use providerType for skipped providers functionality Given I have a discovery service And I have multiple providers with different types: | Provider Type | Should Skip | | Evm | false | | Solana | true | | Btc | true | When I configure skippedProviders to include ["Solana", "Btc"] And I perform account discovery Then only the Evm provider should be used for discovery And Solana provider should be skipped And Btc provider should be skipped And the service should identify providers by their providerType @provider-type @type-safety Scenario: Provider type ensures type safety at compile time Given I have TypeScript compilation enabled When I assign a valid AccountProviderType to providerType Then the code should compile without errors And type checking should pass And IntelliSense should provide proper autocomplete @provider-type @type-safety @error-handling Scenario: Invalid provider type causes compile-time error Given I have TypeScript compilation enabled When I attempt to assign an invalid string to providerType Then TypeScript should show a compilation error And the error should indicate the expected AccountProviderType values And the code should not compile until fixed @provider-type @backwards-compatibility Scenario: Provider type change maintains API compatibility Given existing code that uses account providers When the providerType property is accessed Then the property should return an AccountProviderType value And existing functionality should continue to work And no breaking changes should be introduced to public APIs @account-discovery @performance Scenario: Account discovery performs efficiently without groupIndex constraint Given I have providers for multiple blockchain types And each provider has accounts at various indices When I perform account discovery across all providers Then the discovery should complete within acceptable time limits And memory usage should remain within reasonable bounds And the discovery should not cause performance degradation @provider-type @integration Scenario: Multiple providers can coexist with different types Given I have the following providers configured: | Provider Type | Instance Name | | Evm | EthereumProvider | | Solana | SolanaProvider | When I access each provider's type Then EthereumProvider.providerType should be AccountProviderType.Evm And SolanaProvider.providerType should be AccountProviderType.Solana And both providers should function independently And provider types should not conflict with each other @account-discovery @error-handling Scenario: Account discovery handles provider errors gracefully Given I have multiple account providers And one provider throws an error during discovery When I perform account discovery Then the discovery should continue with other providers And the error should be logged appropriately And successful providers should still create accounts And the overall discovery process should not fail completely @provider-type @documentation Scenario: Provider type enum is properly documented Given the AccountProviderType enum is defined When I check the JSDoc documentation Then each enum value should have clear documentation And the purpose of each provider type should be explained And usage examples should be provided where appropriate And the documentation should be up to date with the implementation ```
1 parent 8cb6d45 commit 2dc83be

2 files changed

Lines changed: 22 additions & 4 deletions

File tree

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
import { AccountProviderType } from './provider';
2+
3+
describe('AccountProviderType', () => {
4+
it('has expected values', () => {
5+
expect(AccountProviderType).toStrictEqual({
6+
Evm: 'Evm',
7+
Solana: 'Solana',
8+
Btc: 'Btc',
9+
});
10+
});
11+
});

packages/account-api/src/api/provider.ts

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,19 @@
11
import type { EntropySourceId, KeyringAccount } from '@metamask/keyring-api';
22

3+
export enum AccountProviderType {
4+
Evm = 'Evm',
5+
Solana = 'Solana',
6+
Btc = 'Btc',
7+
}
8+
39
/**
410
* An account provider is reponsible of providing accounts to an account group.
511
*/
612
export type AccountProvider<Account extends KeyringAccount> = {
13+
/**
14+
* The type of the provider.
15+
*/
16+
providerType: AccountProviderType;
717
/**
818
* Gets an account for a given ID.
919
*
@@ -33,18 +43,15 @@ export type AccountProvider<Account extends KeyringAccount> = {
3343
}) => Promise<Account[]>;
3444

3545
/**
36-
* Discover accounts for a given entropy source and a given group
37-
* index.
46+
* Discover accounts for a given entropy source.
3847
*
3948
* NOTE: This method needs to also create the discovered accounts.
4049
*
4150
* @param options - Options.
4251
* @param options.entropySource - Entropy source to use.
43-
* @param options.groupIndex - Group index to use.
4452
* @returns The list of discovered and created accounts.
4553
*/
4654
discoverAndCreateAccounts: (options: {
4755
entropySource: EntropySourceId;
48-
groupIndex: number;
4956
}) => Promise<Account[]>;
5057
};

0 commit comments

Comments
 (0)