Conversation
WalkthroughThis pull request updates the processing of transaction values in the ExchangeAction component and enhances the token mapping in the tokensData service. In the ExchangeAction component, transaction values are now converted using BigNumber from ethers and formatted using formatEther from viem before being batched. In the tokensData service, conditional logic adjusts token names and symbols based on specific criteria and filters out certain tokens based on contract addresses. No changes were made to the exported entities in either module. Changes
Sequence Diagram(s)sequenceDiagram
participant UI as User Interface
participant EA as ExchangeAction Component
participant BN as BigNumber Conversion
participant FE as FormatEther Function
participant BT as Batch Processor
UI->>EA: Click Exchange Button
EA->>BN: Convert transaction value
BN-->>EA: Return BigInt value
EA->>FE: Format BigInt to Ether string
FE-->>EA: Return formatted value
EA->>BT: addToBatch(formatted value)
sequenceDiagram
participant Data as loadTokensData Function
participant Mapper as Token Mapper
participant Filter as Token Filter
Data->>Mapper: Map tokens data for each blockchain
Mapper-->>Data: Apply conditional name & symbol changes
Data->>Filter: Exclude tokens by contract check and filter nulls
Filter-->>Data: Return cleaned, updated token list
Suggested reviewers
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Deploying x with
|
| Latest commit: |
a3fceb7
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://c9a2e8ae.x-e62.pages.dev |
| Branch Preview URL: | https://fix-pro-3156-exchange-gnosis.x-e62.pages.dev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
src/apps/the-exchange/components/ExchangeAction/ExchangeAction.tsx (1)
3-5: Consider avoiding mixing libraries for big number manipulation.
You’re importingBigNumberfromethersandformatEtherfromviem. While this can work, relying on multiple libraries to handle big-number logic can introduce confusion and subtle inconsistencies. If possible, consolidate the handling of big-number arithmetic and Ether formatting under a single library for more predictable behavior.src/services/tokensData.ts (1)
50-84: Consolidate special token handling and confirm downstream usage.
You’re conditionally renaming XDAI to WXDAI and Ethereum to WETH when the contract address differs from the native placeholder (0xeeee...). While this approach is valid, consider encapsulating these transformations in a helper function or data structure to reduce repetition and facilitate maintenance if new cases emerge. Also verify that no consumer of this data still relies on the original token names/symbols.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/apps/the-exchange/components/ExchangeAction/ExchangeAction.tsx(5 hunks)src/services/tokensData.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: unit-tests
- GitHub Check: build
- GitHub Check: Cloudflare Pages
🔇 Additional comments (2)
src/apps/the-exchange/components/ExchangeAction/ExchangeAction.tsx (2)
125-127: Ensure transaction value is correctly formatted for cross-chain offers.
Passing the output offormatEther(bigIntValue)might lead to unexpected results if the underlying cross-chain transactions require a WEI integer value. Double-check the entire flow to confirm that the contract calls and signing methods align with this decimal representation.
109-109:Details
❓ Verification inconclusive
Verify transaction value usage in addToBatch.
Here,value: integerValueis a string fromformatEther. Confirm whetheraddToBatchis designed to handle decimal ETH strings or if it requires a WEI-based format.
🏁 Script executed:
#!/bin/bash # Search for the definition of addToBatch to see its parameter types or usage. rg -A 15 "function addToBatch"Length of output: 32
I'm not seeing any reference to a definition or usage of
addToBatchwith the initial search. To improve our verification, let's run an updated search for any occurrence ofaddToBatchin the codebase—which may reveal its declaration or usage pattern (e.g. via arrow functions, class methods, or assignments). This should help clarify if it expects a WEI value or a decimal string fromformatEther.Below is a script to recursively search for any instance of
addToBatchwith some context:Once we see the output from this search, we can determine whether a manual verification is needed to check if
addToBatchexpects a WEI-based format.
🏁 Script executed:
#!/bin/bash rg -n -A 10 "addToBatch" .Length of output: 15680
Action Required: Verify Transaction Value Format
Upon inspection,
addToBatch(defined insrc/providers/GlobalTransactionsBatchProvider.tsx) simply accepts and stores the transaction object without performing any conversion on its fields. Thevalueproperty is being passed asintegerValue—a string output fromformatEther(a decimal representation of ETH). There’s no internal logic converting this value to a WEI-based format.
- Please verify that downstream processes consuming this transaction are designed to work with a decimal ETH string.
- If a WEI-based value is required, convert
integerValueusing the appropriate method (for example, utilizingparseEtheror another conversion utility) before passing it toaddToBatch.
| const { value } = bestOffer.offer.transactions[i]; | ||
| const bigIntValue = BigNumber.from(value).toBigInt(); | ||
| const integerValue = formatEther(bigIntValue); |
There was a problem hiding this comment.
Check for mismatch in transaction value representation.
Using formatEther(bigIntValue) produces a decimal string (e.g. "0.5" for half an ETH), whereas most lower-level transaction methods expect a value designated in WEI. Ensure addToBatch and subsequent transaction logic will properly interpret the returned string. If it expects a WEI amount, consider passing the raw wei value instead (e.g., a BigInt or a hex string).
| chainId: chainNameToChainIdTokensData(swapToken?.blockchain) || 0, | ||
| to: stepTransactions[i].to || '', | ||
| value: ethers.BigNumber.from(stepTransactions[i].value), | ||
| value: integerValue, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Reconfirm the final transaction value format.
As with previous segments, value: integerValue is a decimal string from formatEther, which could introduce confusion or errors if the receiving function or contract requires a raw WEI value.
2 participants
Description
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Summary by CodeRabbit