Skip to content

Conversation

@ulissesferreira
Copy link
Contributor

Extreme token amounts caused two issues:

  • "You receive" showed NaN when parseFloat returned invalid values
  • Transaction history failed StringNumber validation due to scientific notation

Add validation for parsed values in TransactionScanService and use BigNumber's toFixed() in TransactionsMapper to ensure decimal string output.

@ulissesferreira ulissesferreira requested a review from a team as a code owner February 3, 2026 16:34
Extreme token amounts caused two issues:
- "You receive" showed NaN when parseFloat returned invalid values
- Transaction history failed StringNumber validation due to scientific notation

Add validation for parsed values in TransactionScanService and use
BigNumber's toFixed() in TransactionsMapper to ensure decimal string output.
@ulissesferreira ulissesferreira force-pushed the NEB-386/fix-nan-display-and-scientific-notation branch from a14470c to b247f93 Compare February 3, 2026 16:46
@@ -14,7 +14,7 @@ import type {
import type { Network } from '../../constants';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leverage our utility to adjust decimals powered by BigNumber.js to make sure we have no problems on transactions mapping because we were mapping some to use scientific notation (as seen here https://consensys.slack.com/archives/C09QLE417UY/p1769521271407099?thread_ts=1769503457.145259&cid=C09QLE417UY). The problem with scientific notation is it gets rejected by the client's StringNumber validation. The Snap needs to send the value as-is

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants