-
-
Notifications
You must be signed in to change notification settings - Fork 277
Use new assets state in TransactionPayController (behind feature flag) #8163
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
base: main
Are you sure you want to change the base?
Changes from all commits
6e407d3
5b84ccc
1e09ec5
e8ab445
73586b3
3b760ee
3769141
dc87022
199802c
deb5f05
d883110
d8a0c2f
61e0890
20e274c
0f01832
6638faa
9b43494
61aec42
ab40146
fa786f6
e2f2a16
81d2a9d
40d4ea0
6e94df1
be776f1
9323849
f28af7a
5d0b20b
e7f200b
d2899f6
1f5463f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -297,6 +297,31 @@ export function getSlippage( | |
| return slippage; | ||
| } | ||
|
|
||
| /** | ||
| * Get the AssetsUnifyState feature flag state. | ||
| * | ||
| * @param messenger - Controller messenger. | ||
| * @returns True if the assets unify state feature is enabled, false otherwise. | ||
| */ | ||
| export function getAssetsUnifyStateFeature( | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do we need to pivot on a feature flag at this point? Could we not test the new controller for a time with standard client flows, and refactor this in one go when stable? I'm naturally concerned given the risk to key in-development flows like MUSD, Perps, and Predict.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We cannot migrate in one go. There is a very complex network of selectors using other selectors that depend on our state, and we want to be able to work in manageable PR sizes. What we have done so far is create a root selector for every single legacy piece of state and make it return the old state if the flag is off, and the new state in the shape of the old if the flag is on. We have hunted every single reference to legacy stated and replaced it with those selectors (in extension). We are now doing the same for the two controllers that fetch from those controller states as well. Once that is done, we can safely turn the feature flag on in dev for QA to test. Once we are confident there are no regressions we can then start turning it on in other environments. Not only that, but before we turn it on in dev we need to ensure all fixtures and tests that use legacy state also have the new controller state, otherwise those tests will fail. This would have been very difficult to achieve in one PR without feature flags. |
||
| messenger: TransactionPayControllerMessenger, | ||
| ): boolean { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. QQ if we want to test this , what is the way to turn this to true ?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Currently only controlled by remote feature flags, unsure how much work would be required if we want to force to true.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. By doing black magic cjs updates in the client.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. With that said, if that cjs change is done with a patch and directly at the feature flag controller, it can be used to test selector changes too. |
||
| const state = messenger.call('RemoteFeatureFlagController:getState'); | ||
| const assetsUnifyState = state.remoteFeatureFlags.assetsUnifyState as | ||
| | { | ||
| enabled: boolean; | ||
| featureVersion: string | null; | ||
| } | ||
| | undefined; | ||
|
|
||
| const AssetsUnifyStateFeatureVersion = '1'; | ||
|
|
||
| return ( | ||
| Boolean(assetsUnifyState?.enabled) && | ||
| assetsUnifyState?.featureVersion === AssetsUnifyStateFeatureVersion | ||
| ); | ||
| } | ||
|
|
||
| /** | ||
| * Get a value from a record using a case-insensitive key lookup. | ||
| * | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
assets-controller is the new controller that we are migrating towards and that will hold the state.
Once the flag is fully turned on, we will come back here and delete all the old code and the old dependency.