Fixing incorrectly typed token decimal attribute#10666
Conversation
Builds ready [c8b5794]
Page Load Metrics (1277 ± 101 ms)
|
|
|
||
| function transformState(state) { | ||
| const newState = state; | ||
|
|
There was a problem hiding this comment.
A migration of accountTokens will also be needed. Check out this PR which is also about to migrate tokens and accountTokens: https://github.com/MetaMask/metamask-extension/pull/10593/files#diff-0ee44923cc3a183d3803fea2022e1b17f127940f603909b954588cc7c7aa2439R47
And for reference on what those are, see this thread: https://consensys.slack.com/archives/GTQAGKY5V/p1615395521395500?thread_ts=1615332992.380200&cid=GTQAGKY5V
There was a problem hiding this comment.
Good catch here 👍 I believe having these incorrectly typed in part of accountTokens does not produce the UI error in question, but for structural parity they should absolutely be the same.
There was a problem hiding this comment.
I see that this is addressed now, but for future reference: it does end up indirectly causing the problem, because tokens gets derived from accountTokens whenever the user switches accounts or networks.
There was a problem hiding this comment.
@Gudahtt - ah, thank you for pointing this out
danjm
left a comment
There was a problem hiding this comment.
I left one comment that needs to be addressed
c8b5794 to
84facd5
Compare
app/scripts/migrations/054.js
Outdated
| } | ||
| newState.PreferencesController.tokens = tokens; | ||
|
|
||
| const { accountTokens } = newState.PreferencesController || {}; |
There was a problem hiding this comment.
I tried to clean up this pyramid but the linter wasn't having it ;)
Builds ready [84facd5]
Page Load Metrics (807 ± 80 ms)
|
app/scripts/migrations/054.js
Outdated
| const { tokens } = newState.PreferencesController || []; | ||
| if (Array.isArray(tokens)) { | ||
| for (const token of tokens) { | ||
| if (token.decimals === '0') { |
There was a problem hiding this comment.
Are you sure that 0 was the only possible string? 🤔 We could check the type here instead.
The same goes for this comparison in the accountTokens loop as well of course
There was a problem hiding this comment.
@Gudahtt - 0 was the only default decimal value I had seen occur during testing of numerous NFT's, but I think you're right that things should extend to check for strings in general. I can make needed updates here
There was a problem hiding this comment.
per our conversation, we are now doing general string primitive checks, as well as looking for an potential corruption that could result in being unable to perform a numerical conversion.
84facd5 to
d2af4f2
Compare
Builds ready [d2af4f2]
Page Load Metrics (897 ± 100 ms)
|
d2af4f2 to
4e3d223
Compare
| for (const token of validTokens) { | ||
| // In the case of a decimal value type string, set to 0. | ||
| if (typeof token.decimals === 'string') { | ||
| // eslint-disable-next-line radix |
There was a problem hiding this comment.
note, per discussion with @Gudahtt we'll let the radix be inferred
Builds ready [4e3d223]
Page Load Metrics (591 ± 11 ms)
|
Gudahtt
left a comment
There was a problem hiding this comment.
LGTM! Couple of comment issues and one suggestion, but looks good otherwise.
4e3d223 to
6040195
Compare
6040195 to
2d32d6f
Compare
Builds ready [2d32d6f]
Page Load Metrics (600 ± 14 ms)
|
Fixes: #10665
Essentially if you are to add an NFT, or something with a 0 decimal value that does not allow for override, that gets saved to the state as
"0"as opposed to 0, so we causing some component issues. Migrations added to back-fix the issue.Manual testing steps:
Defined in issue