feat(synapse-interface): refund RFQ transaction [SLT-272] #3197
Conversation
bigboydiamonds
requested review from
abtestingalpha and
aureliusbtc
as code owners
WalkthroughThe changes introduce a new transaction status, 'refunded', across various components and hooks within the Synapse interface. This update includes modifications to interfaces, props, and rendering logic to accommodate the refund status. Additionally, new localization entries for multiple languages have been added to support the updated transaction messaging. The overall structure of related components remains intact, but their functionality is enhanced to provide better user feedback regarding transaction refunds. Changes
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 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
Documentation and Community
|
bigboydiamonds
changed the title
Deploying sanguine-fe with
|
| Latest commit: |
446aad3
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://df8747cf.sanguine-fe.pages.dev |
| Branch Preview URL: | https://fe-refund-transaction.sanguine-fe.pages.dev |
Deploying sanguine with
|
| Latest commit: |
446aad3
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://321e39d4.sanguine.pages.dev |
| Branch Preview URL: | https://fe-refund-transaction.sanguine.pages.dev |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3197 +/- ##
====================================================
- Coverage 39.46606% 26.23968% -13.22638%
====================================================
Files 479 677 +198
Lines 26932 49307 +22375
Branches 342 82 -260
====================================================
+ Hits 10629 12938 +2309
- Misses 15557 35051 +19494
- Partials 746 1318 +572
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Bundle ReportChanges will decrease total bundle size by 26.34MB (-73.67%) ⬇️. This is within the configured threshold ✅ Detailed changes
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Outside diff range and nitpick comments (18)
packages/synapse-interface/components/_Transaction/helpers/calculateEstimatedTimeStatus.ts (2)
24-24: LGTM: New refund check condition.The introduction of
isCheckTxForRefundand its inclusion in the return object directly supports the PR objective of implementing refund functionality for RFQ transactions. The implementation is consistent with the existing pattern in the function.Consider renaming
isCheckTxForRefundtoshouldCheckTxForRefundfor clarity, as it indicates an action that should be taken rather than a state. This would make it consistent with the naming convention of other boolean variables in the function that start with "is".- const isCheckTxForRefund = elapsedTime > fourHoursInSeconds + const shouldCheckTxForRefund = elapsedTime > fourHoursInSeconds return { // ... other properties - isCheckTxForRefund, + shouldCheckTxForRefund, }Also applies to: 38-38
Line range hint
1-40: Overall, changes align well with PR objectives.The modifications successfully introduce the ability to track refund status for RFQ transactions, aligning perfectly with the PR objectives. The implementation is consistent with the existing code structure and doesn't introduce any apparent issues.
Consider updating the function's JSDoc comment to include information about the new
isCheckTxForRefund(orshouldCheckTxForRefundif renamed) property in the return object. This will help maintain clear documentation for future developers./** * Calculates remaining time based on given initial, current, and estimated times. * * @param currentTime - The current time, as a unix timestamp. * @param initialTime - The initial time, as a unix timestamp. * @param estimatedTime - The estimated duration to calculate, in seconds. + * @returns An object containing various time-related statuses, including a flag + * indicating whether the transaction should be checked for a refund. */packages/synapse-interface/components/_Transaction/components/TransactionSupport.tsx (2)
16-18: Simplified logic for 'reverted' statusThe change from
isRevertedtostatus === 'reverted'is good. It's consistent with the new prop type and simplifies the logic.For consistency with the other status checks, consider using a template literal for the translation key:
- {status === 'reverted' && ( - <div>{t('Transaction reverted, funds returned')}</div> + {status === 'reverted' && ( + <div>{t(`Transaction ${status}, funds returned`)}</div> )}This change would make it easier to maintain consistent messaging across different statuses.
20-23: New rendering logic for 'refunded' statusThe addition of a specific rendering condition for the 'refunded' status is good. It aligns with the PR objective and follows the existing pattern for other statuses.
To improve flexibility and reduce duplication, consider refactoring the 'reverted' and 'refunded' cases:
const statusMessages = { reverted: 'Transaction reverted, funds returned', refunded: 'Transaction refunded, funds returned', }; {['reverted', 'refunded'].includes(status) && ( <div>{t(statusMessages[status as keyof typeof statusMessages])}</div> )}This approach would make it easier to add or modify status messages in the future.
packages/synapse-interface/components/_Transaction/components/TimeRemaining.tsx (1)
15-15: LGTM! Consider using a TypeScript union type for better maintainability.The addition of the 'refunded' status to the prop type definition is correct and aligns with the PR objective.
For improved maintainability, consider defining a union type for the status:
type TransactionStatus = 'pending' | 'completed' | 'reverted' | 'refunded'; // Then use it in the prop definition: status: TransactionStatusThis approach would make it easier to update the status types in the future and reuse them across different components if needed.
packages/synapse-interface/utils/hooks/use_TransactionsListener.ts (1)
Line range hint
1-63: Consider optimizations and error handling improvementsWhile the overall structure of the hook is sound, consider the following suggestions for optimization and robustness:
Performance: The
useEffecthook runs on every change topendingBridgeTransactionsortransactions. Consider usinguseMemofor expensive computations oruseCallbackfor function memoization to optimize re-renders.Error Handling: Add try-catch blocks around the dispatch calls to handle potential errors gracefully.
Typescript: Consider using more specific types instead of
anyfor better type safety, especially for thetxobject in theforEachloop.Dependency Array: Ensure all variables used inside the
useEffectare included in the dependency array to avoid potential stale closures.Here's a sample of how you might implement some of these suggestions:
import { useEffect, useCallback } from 'react' // ... other imports ... export const use_TransactionsListener = () => { // ... existing code ... const processPendingTransactions = useCallback(() => { if (checkTransactionsExist(pendingBridgeTransactions)) { pendingBridgeTransactions.forEach((tx: PendingBridgeTransaction) => { // ... existing checks ... if (txnConfirmed && !txnExists) { try { dispatch( addTransaction({ // ... existing properties ... routerAddress: tx.routerAddress, // ... other properties ... }) ) } catch (error) { console.error('Failed to add transaction:', error) // Consider adding more robust error handling here } } }) } }, [pendingBridgeTransactions, transactions, dispatch, address]) useEffect(() => { processPendingTransactions() }, [processPendingTransactions]) return null }This refactored version uses
useCallbackto memoize theprocessPendingTransactionsfunction, adds basic error handling, and ensures all dependencies are properly declared.packages/synapse-interface/components/_Transaction/helpers/useBridgeTxUpdater.ts (1)
31-32: Update JSDoc to include new parameterThe new
isTxRefundedparameter is correctly added to the function signature. However, the JSDoc comment above the function should be updated to include a description of this new parameter.Consider updating the JSDoc comment as follows:
* @param {boolean} isTxReverted - Whether bridge transaction was reverted, queried on-chain. + * @param {boolean} isTxRefunded - Whether the RFQ transaction has been refunded after the deadline. */packages/synapse-interface/slices/_transactions/reducer.ts (3)
21-21: LGTM: Addition ofrefundedstatusThe new
refundedstatus in the_TransactionDetailsinterface'sstatusproperty directly addresses the PR objective. This addition will allow for better tracking of refunded RFQ transactions.Consider improving readability by formatting the union type vertically:
status: | 'pending' | 'completed' | 'reverted' | 'refunded'This format can make it easier to add or remove statuses in the future.
91-103: LGTM: Implementation ofrefundTransactionactionThe
refundTransactionaction is well-implemented and aligns with the PR objective of handling refunded transactions. It follows the established pattern for status update actions in this slice.Consider adding a console warning or throwing an error when the transaction is not found:
if (txIndex !== -1) { state.transactions[txIndex].status = 'refunded' } else { console.warn(`Transaction with hash ${originTxHash} not found for refund.`) }This can help with debugging in case of unexpected behavior.
Missing Usage of
refundTransactionActionThe
refundTransactionaction introduced inpackages/synapse-interface/slices/_transactions/reducer.tsis not imported or used in other parts of the codebase. This may indicate that the action is defined but not dispatched, which could lead to incomplete refund functionality.
- Ensure that the
refundTransactionaction is dispatched appropriately in relevant components or middleware.🔗 Analysis chain
Line range hint
1-118: Summary: Successful implementation of refund functionalityThe changes in this file successfully implement the refund functionality for RFQ transactions as outlined in the PR objectives. Key points:
- The
_TransactionDetailsinterface has been updated to includerouterAddressand the newrefundedstatus.- A new
refundTransactionaction has been implemented and exported.- The changes maintain consistency with the existing code structure and patterns.
These modifications enhance the transaction management capabilities of the system, allowing for better tracking and handling of refunded transactions.
To ensure the changes are properly integrated, please run the following verification script:
This script will help identify any places where the new functionality should be integrated or where additional updates might be necessary.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of the new refundTransaction action and refunded status # Test 1: Check for imports of the new refundTransaction action echo "Checking for imports of refundTransaction:" rg --type typescript "import.*refundTransaction.*from.*_transactions/reducer" # Test 2: Check for uses of the new refunded status echo "Checking for uses of the refunded status:" rg --type typescript "'refunded'" # Test 3: Check for uses of the new routerAddress property echo "Checking for uses of the routerAddress property:" rg --type typescript "routerAddress"Length of output: 558
Script:
#!/bin/bash # Description: Verify the usage of the new refundTransaction action and refunded status # Test 1: Check for imports of the new refundTransaction action echo "Checking for imports of refundTransaction:" rg "import.*refundTransaction.*from.*_transactions/reducer" -g "*.ts" -g "*.tsx" # Test 2: Check for uses of the refunded status echo "Checking for uses of the refunded status:" rg "'refunded'" -g "*.ts" -g "*.tsx" # Test 3: Check for uses of the routerAddress property echo "Checking for uses of the routerAddress property:" rg "routerAddress" -g "*.ts" -g "*.tsx"Length of output: 9947
packages/synapse-interface/components/_Transaction/components/AnimatedProgressBar.tsx (2)
20-20: LGTM: Type definition updated correctlyThe type definition for the
statusprop has been properly updated to include the new 'refunded' status, which is consistent with the PR objectives and the JSDoc comment.Consider using a TypeScript enum or a union type alias for the status values to improve maintainability and reduce the risk of typos. For example:
type TransactionStatus = 'pending' | 'completed' | 'reverted' | 'refunded'; // Then use it in the component props: status: TransactionStatusThis would make it easier to update the status values in the future and ensure consistency across the codebase.
28-28: Consider separating 'refunded' from error statesThe condition for
isErrorhas been updated to include the new 'refunded' status, which is consistent with the PR objectives. However, classifying a refunded transaction as an error might not provide the best user experience.Consider separating the 'refunded' status from the error states. Refunds are often part of normal business operations and may not necessarily indicate an error condition. You might want to handle 'refunded' transactions differently in the UI to provide clearer feedback to the user.
For example, you could introduce a new variable:
const isRefunded = status === 'refunded'; const isError = status === 'reverted';Then, update the component's logic to handle 'refunded' status separately from error states. This would allow for more flexible styling and messaging specific to refunded transactions.
packages/synapse-interface/constants/abis/fastBridgeRouter.json (1)
1-387: Overall, the ABI is well-defined but requires careful implementationThe ABI for the FastBridgeRouter contract is comprehensive and well-structured. It covers essential functionality for token swapping, cross-chain bridging, and contract management. However, given the complexity and potential risks associated with such operations, consider the following recommendations:
- Implement thorough input validation for all functions, especially
adapterSwapandbridge.- Ensure proper access control mechanisms are in place for state-changing functions.
- Implement comprehensive unit tests covering all possible execution paths.
- Consider conducting a professional security audit of the contract implementation.
- Implement a contract upgradeability pattern to allow for future improvements or bug fixes.
packages/synapse-interface/messages/jp.json (1)
311-311: LGTM: Accurate translation with a minor suggestionThe Japanese translation "取引が返金され、資金が戻されました" for "Transaction refunded, funds returned" is accurate and follows the polite form used throughout the file. However, to enhance clarity, consider the following minor adjustment:
- "Transaction refunded, funds returned": "取引が返金され、資金が戻されました", + "Transaction refunded, funds returned": "取引が返金され、資金が返還されました",This change replaces "戻されました" with "返還されました", which more precisely conveys the sense of "returned" in a financial context. Both versions are correct, but "返還" is more commonly used in formal financial communications.
packages/synapse-interface/messages/en-US.json (1)
309-311: LGTM with a minor suggestion for consistency.The new entries for the refunded status are well-placed and clearly worded. They align with the PR objectives and follow the existing pattern in the localization file.
For consistency with the "Reverted" status message, consider changing:
- "Transaction refunded, funds returned": "Transaction refunded, funds returned", + "Transaction refunded, funds returned": "Transaction refunded, funds returned.",This adds a period at the end of the message, matching the format of the "Reverted" status message.
packages/synapse-interface/messages/tr.json (1)
309-311: LGTM with a minor suggestion.The new translations for "Refunded" and "Transaction refunded, funds returned" are correctly implemented and align with the PR objectives. These additions will help Turkish users understand the new 'refunded' status for RFQ transactions.
For consistency with other entries in this file, consider capitalizing the first letter of each word in the Turkish translation for "Transaction refunded, funds returned".
Consider applying this change:
- "Transaction refunded, funds returned": "İşlem iade edildi, fonlar geri gönderildi", + "Transaction refunded, funds returned": "İşlem İade Edildi, Fonlar Geri Gönderildi",packages/synapse-interface/constants/abis/fastBridge.json (1)
807-850: Custom errors enhance gas efficiency and error handling.The ABI defines a comprehensive set of custom errors, which is a gas-efficient approach to error handling. These errors cover various failure scenarios, including:
- Access control issues (e.g., AccessControlUnauthorizedAccount)
- Timing-related problems (e.g., DeadlineExceeded, DeadlineNotExceeded)
- Incorrect input validation (e.g., AmountIncorrect, ChainIncorrect)
- Contract-specific issues (e.g., DisputePeriodNotPassed, TransactionRelayed)
This approach provides more informative error messages while optimizing gas usage. The inclusion of timing-related errors suggests careful handling of deadline-sensitive operations, which is crucial for a bridge contract.
Consider adding a custom error for the refund operation (e.g.,
RefundNotAllowed) to provide more specific error handling for the new refund functionality.packages/synapse-interface/components/_Transaction/_Transaction.tsx (1)
202-204: Clarify Menu Item Text for Refunded TransactionsThe condition
isTxReverted || isTxRefundeddisplays the text'Clear notification'. For better user clarity, consider specifying the notification type.Suggestion:
text={ isTxReverted ? t('Clear reverted notification') : isTxRefunded ? t('Clear refund notification') : t('Clear transaction') }This change provides more specific information to the user.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (21)
- packages/synapse-interface/components/_Transaction/_Transaction.tsx (6 hunks)
- packages/synapse-interface/components/_Transaction/_Transactions.tsx (1 hunks)
- packages/synapse-interface/components/_Transaction/components/AnimatedProgressBar.tsx (2 hunks)
- packages/synapse-interface/components/_Transaction/components/TimeRemaining.tsx (2 hunks)
- packages/synapse-interface/components/_Transaction/components/TransactionSupport.tsx (1 hunks)
- packages/synapse-interface/components/_Transaction/helpers/calculateEstimatedTimeStatus.ts (2 hunks)
- packages/synapse-interface/components/_Transaction/helpers/useBridgeTxUpdater.ts (3 hunks)
- packages/synapse-interface/components/_Transaction/helpers/useTxRefundStatus.ts (1 hunks)
- packages/synapse-interface/constants/abis/fastBridge.json (1 hunks)
- packages/synapse-interface/constants/abis/fastBridgeRouter.json (1 hunks)
- packages/synapse-interface/messages/ar.json (1 hunks)
- packages/synapse-interface/messages/en-US.json (1 hunks)
- packages/synapse-interface/messages/es.json (1 hunks)
- packages/synapse-interface/messages/fr.json (1 hunks)
- packages/synapse-interface/messages/jp.json (1 hunks)
- packages/synapse-interface/messages/tr.json (1 hunks)
- packages/synapse-interface/messages/zh-CN.json (1 hunks)
- packages/synapse-interface/pages/state-managed-bridge/index.tsx (1 hunks)
- packages/synapse-interface/slices/_transactions/reducer.ts (3 hunks)
- packages/synapse-interface/slices/transactions/actions.ts (1 hunks)
- packages/synapse-interface/utils/hooks/use_TransactionsListener.ts (1 hunks)
🔇 Additional comments (39)
packages/synapse-interface/components/_Transaction/helpers/calculateEstimatedTimeStatus.ts (1)
19-19: LGTM: New constant for refund check threshold.The introduction of
fourHoursInSecondsis a good practice. It clearly defines the threshold for checking if a transaction should be considered for a refund, which aligns with the PR objective of implementing refund functionality for RFQ transactions.packages/synapse-interface/components/_Transaction/components/TransactionSupport.tsx (3)
4-8: Improved type safety for thestatuspropThe change from a generic
stringtype to a union of specific string literals ('pending', 'completed', 'reverted', 'refunded') for thestatusprop is a good improvement. This enhances type safety and makes the component's API more explicit.This change:
- Aligns with the PR objective of introducing a 'refunded' status.
- Reduces the likelihood of runtime errors by catching invalid status values at compile-time.
- Improves code readability and self-documentation.
24-25: Updated logic for 'pending' statusThe explicit check for 'pending' status is good. It's consistent with the new prop type and other status checks in the component.
This change improves code clarity and maintains the existing functionality for pending transactions.
Line range hint
1-50: Overall assessment of TransactionSupport component changesThe changes to the TransactionSupport component are well-implemented and align with the PR objectives. The introduction of the 'refunded' status and the improved type safety for the
statusprop enhance the component's functionality and robustness.Key improvements:
- More specific prop types for better type safety.
- Consistent handling of different transaction statuses.
- Addition of the 'refunded' status to support the new use case.
The suggestions provided in the review comments, if implemented, would further improve the component's maintainability and flexibility. Great work overall!
packages/synapse-interface/slices/transactions/actions.ts (1)
19-19: Approved addition ofrouterAddress. Please provide more context.The addition of
routerAddressto thePendingBridgeTransactioninterface is approved. However, to improve code clarity and maintainability:
- Could you please clarify the purpose of
routerAddressand how it will be used in the context of pending bridge transactions?- Consider adding a brief comment above this property to explain its purpose and any constraints (e.g., format expectations).
To ensure this change doesn't break existing code, please run the following script:
This will help identify any places where the code might need to be updated to include the new
routerAddressproperty.packages/synapse-interface/components/_Transaction/components/TimeRemaining.tsx (2)
Line range hint
1-58: Summary: Successfully implemented 'refunded' status in TimeRemaining componentThe changes in this file effectively introduce the new 'refunded' status to the TimeRemaining component. The implementation is consistent with existing patterns, maintains code quality, and aligns with the PR objective. The modifications are minimal and focused, which reduces the risk of unintended side effects.
Key points:
- The status prop type has been updated to include 'refunded'.
- A new conditional rendering block for the 'refunded' status has been added.
- The changes maintain the component's clear and understandable logic.
Overall, these changes enhance the component's functionality to handle refunded transactions without compromising its existing behavior.
39-45: LGTM! Verify the 'Refunded' translation key.The implementation of the 'refunded' status rendering is correct and consistent with the existing pattern.
Please ensure that the 'Refunded' translation key exists in all relevant language files. Run the following script to verify:
If the key is missing in any language file, please add it to maintain consistency across all supported languages.
✅ Verification successful
LGTM! The 'Refunded' translation key exists in the language files.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for the 'Refunded' translation key in language files # Test: Search for 'Refunded' key in language files rg --type json '"Refunded"' packages/synapse-interface/lang/Length of output: 135
Script:
#!/bin/bash # Description: Search for the 'Refunded' translation key in all JSON language files fd --type f --extension json --exec rg '"Refunded"' {} +Length of output: 10707
packages/synapse-interface/utils/hooks/use_TransactionsListener.ts (1)
53-53: LGTM: Addition ofrouterAddressto transaction objectThe addition of
routerAddressto the transaction object is consistent with the PR objective of enhancing transaction management. This change will allow for better tracking and handling of transactions, potentially supporting the new 'refunded' status mentioned in the PR summary.Let's verify if this change is consistent across the codebase:
✅ Verification successful
Let's update the search to include both
tsandtsxfile types to ensure all TypeScript files are covered:
Let's modify the search to target
.tsand.tsxfiles explicitly:
Verified:
routerAddressis consistently used across the codebaseThe addition of
routerAddressto the transaction object is consistently implemented across all relevant files, ensuring uniform transaction management throughout the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for consistency of routerAddress usage in transaction objects # Search for other occurrences of transaction object creation or usage rg --type typescript -e 'addTransaction\(' -e 'PendingBridgeTransaction' -A 10 -B 5Length of output: 118
Script:
# Description: Check for consistency of routerAddress usage in transaction objects # Search for other occurrences of transaction object creation or usage rg --type ts --type tsx -e 'addTransaction\(' -e 'PendingBridgeTransaction' -A 10 -B 5Length of output: 114
Script:
#!/bin/bash # Description: Check for consistency of routerAddress usage in transaction objects # Search for other occurrences of transaction object creation or usage in .ts and .tsx files rg --glob "*.ts" --glob "*.tsx" -e 'addTransaction\(' -e 'PendingBridgeTransaction' -A 10 -B 5Length of output: 27661
packages/synapse-interface/components/_Transaction/helpers/useBridgeTxUpdater.ts (3)
8-8: LGTM: New import for refundTransaction actionThe import for the
refundTransactionaction is correctly added and aligns with the new functionality for handling refunded transactions.
54-59: LGTM: New useEffect for handling refunded transactionsThe new useEffect hook correctly implements the logic for updating the transaction status to 'refunded' when appropriate. It checks both the
isTxRefundedflag and the current status in the store before dispatching the action, which prevents unnecessary updates.
60-60: LGTM: Improved readabilityThe added empty line improves the code's readability by visually separating the new useEffect hook from the existing one.
packages/synapse-interface/components/_Transaction/_Transactions.tsx (1)
59-59: LGTM! Verify usage in_Transactioncomponent.The addition of the
routerAddressprop is correct and consistent with how other props are passed. This change aligns with the PR objective of enhancing transaction management.To ensure proper implementation, please verify the usage of this new prop in the
_Transactioncomponent:✅ Verification successful
routerAddressprop correctly added and utilized in_Transactioncomponent.The
routerAddressprop is properly passed to the_Transactioncomponent and correctly used within it as a string and type-cast toAddress. This addition aligns with the PR objective of enhancing transaction management and follows consistent patterns used for other props.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check the implementation of routerAddress in _Transaction component # Search for the _Transaction component definition echo "Searching for _Transaction component definition:" ast-grep --lang typescript --pattern 'export const _Transaction = ({ $$$' packages/synapse-interface/components/_Transaction/_Transaction.tsx # Search for usage of routerAddress within the component echo "\nSearching for routerAddress usage in _Transaction component:" rg "routerAddress" packages/synapse-interface/components/_Transaction/_Transaction.tsxLength of output: 888
Script:
#!/bin/bash # Description: Improved search for _Transaction component definition and routerAddress usage # Search for the _Transaction component definition using rg echo "Searching for _Transaction component definition using ripgrep:" rg "export\s+(const|function)\s+_Transaction\s*\(" packages/synapse-interface/components/_Transaction/_Transaction.tsx # Search for usage of routerAddress within the component echo "\nVerifying usage of routerAddress in _Transaction component:" rg "routerAddress" packages/synapse-interface/components/_Transaction/_Transaction.tsxLength of output: 546
Script:
#!/bin/bash # Description: Comprehensive search for _Transaction component definition and routerAddress usage # Search for the _Transaction component definition with various export patterns echo "Searching for _Transaction component definition with different export patterns:" rg "(export\s+default\s+|export\s+(const|function)\s+)_Transaction\s*\(" packages/synapse-interface/components/_Transaction/_Transaction.tsx # If not found, search globally in the repository if [[ $? -ne 0 ]]; then echo "\n_Component _Transaction definition not found in _Transaction.tsx. Searching entire repository:" rg "(_Transaction\s*=\s*|function\s+_Transaction\s*\()" . fi # Search for all imports of _Transaction to identify its source echo "\nSearching for imports of _Transaction component to locate its definition:" rg "import\s+.*_Transaction.*from\s+['\"]" .Length of output: 1889
packages/synapse-interface/slices/_transactions/reducer.ts (2)
17-17: LGTM: Addition ofrouterAddresspropertyThe new
routerAddressproperty in the_TransactionDetailsinterface is a good addition. It enhances the transaction details, which aligns with the PR's objective of improving transaction management.
116-116: LGTM: Export ofrefundTransactionactionThe
refundTransactionaction is correctly exported, which is necessary for it to be used in other parts of the application. This export ensures that the new refund functionality is accessible where needed.packages/synapse-interface/components/_Transaction/components/AnimatedProgressBar.tsx (1)
8-8: LGTM: JSDoc comment updated correctlyThe JSDoc comment for the
statusparameter has been properly updated to include the new 'refunded' status, which aligns with the PR objectives.packages/synapse-interface/constants/abis/fastBridgeRouter.json (5)
1-12: Constructor looks goodThe constructor is well-defined, taking an
owner_parameter of typeaddress. This is a standard practice for setting up initial ownership of the contract.
70-160: Carefully reviewbridgefunction implementationThe
bridgefunction is critical for cross-chain operations. Ensure that:
- The contract properly validates the
chainIdparameter.- The
SwapQuerystructs (originQueryanddestQuery) are correctly processed.- There are safeguards against potential reentrancy attacks, given the
payablenature of the function.- The contract implements proper error handling for failed bridging attempts.
18-301: Other functions appear well-definedThe remaining functions, including view functions like
GAS_REBATE_FLAGandfastBridge, and management functions likesetFastBridgeandtransferOwnership, are appropriately defined for their purposes. Ensure that access control is properly implemented in the contract, especially for functions that modify contract state.
302-346: Events are well-definedThe three events (
FastBridgeSet,OwnershipTransferred, andSwapQuoterSet) are appropriately defined to log important contract state changes. The indexing of parameters inOwnershipTransferredis good for efficient event filtering.
31-68: ReviewadapterSwapfunction carefullyThe
adapterSwapfunction is a key part of the contract, handling token swaps. Ensure that:
- The
rawParamsare properly validated and sanitized in the contract implementation.- The function correctly handles both ERC20 tokens and native ETH (given its
payablestatus).- There are appropriate checks for slippage and deadline in the contract logic.
Consider running the following script to check for similar swap functions in other contracts:
packages/synapse-interface/messages/jp.json (2)
309-309: LGTM: Accurate translation for "Refunded"The Japanese translation "返金済み" for "Refunded" is accurate and concise. It correctly conveys the meaning of a completed refund action.
309-311: Summary: Successfully implemented "refunded" status translationsThe new entries for the "refunded" status have been successfully added to the Japanese localization file. The translations are accurate, consistent with the existing style, and properly placed within the JSON structure. These additions will effectively communicate the refund status to Japanese users of the Synapse interface.
packages/synapse-interface/messages/ar.json (2)
309-311: LGTM: New refund status translations added.The new entries for "Refunded" and "Transaction refunded, funds returned" have been successfully added to the Arabic localization file. These additions align with the PR objective of implementing transaction status updates for refunded RFQ transactions.
309-311: Verify consistency of translations across language files.While the additions look good, it's important to ensure that these new entries are consistently added and correctly translated across all supported language files.
Let's verify the consistency of these new entries across other language files:
This script will help us confirm that the new entries are present in all language files and allow us to compare their translations for consistency.
✅ Verification successful
Consistency of translations verified across all language files. All new entries are present and correctly translated in all supported languages.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if the new refund status entries are present in all language files # and compare their structure to ensure consistency. # Find all JSON files in the messages directory message_files=$(fd -e json . packages/synapse-interface/messages) echo "Checking for 'Refunded' entry:" for file in $message_files; do echo "File: $file" jq -r '."Time"."Refunded" // "Not found"' "$file" echo "---" done echo "Checking for 'Transaction refunded, funds returned' entry:" for file in $message_files; do echo "File: $file" jq -r '."Time"."Transaction refunded, funds returned" // "Not found"' "$file" echo "---" doneLength of output: 4494
packages/synapse-interface/pages/state-managed-bridge/index.tsx (1)
305-305: LGTM: Important addition ofrouterAddressto pending transaction dataThe addition of
routerAddressto the pending bridge transaction object is a valuable enhancement. This information is crucial for transaction tracking and potentially for handling refunds, aligning well with the PR's objective of improving RFQ transaction management.packages/synapse-interface/messages/es.json (1)
309-311: LGTM! New translations for refund status added.The new Spanish translations for "Refunded" and "Transaction refunded, funds returned" have been correctly added. They are consistent with the PR objectives and appear to be grammatically correct.
Let's verify if similar translations have been added to other language files:
✅ Verification successful
Verification Successful: All translations are present across language files.
All added translation entries for "Refunded" and "Transaction refunded, funds returned" are consistently present in all supported language files.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if "Refunded" and "Transaction refunded, funds returned" translations exist in other language files. # Test: Search for "Refunded" in all JSON files within the messages directory echo "Searching for 'Refunded' translations:" rg --type json '"Refunded"' packages/synapse-interface/messages # Test: Search for "Transaction refunded, funds returned" in all JSON files within the messages directory echo "Searching for 'Transaction refunded, funds returned' translations:" rg --type json '"Transaction refunded, funds returned"' packages/synapse-interface/messagesLength of output: 1786
packages/synapse-interface/messages/fr.json (1)
309-311: LGTM! New translations for refund status added correctly.The new French translations for "Refunded" and "Transaction refunded, funds returned" have been added appropriately to the "Time" section of the JSON file. The translations are grammatically correct and consistent with the existing content.
As a minor suggestion, consider adding these translations to other language files (if they exist) to maintain consistency across all supported languages.
packages/synapse-interface/constants/abis/fastBridge.json (5)
1-8: Constructor looks good.The constructor is properly defined with an
_ownerparameter, which is a common pattern for setting up initial ownership of the contract.
9-15: View and pure functions are well-defined and comprehensive.The ABI includes a wide range of view and pure functions that provide access to important contract states and constants. These functions cover various aspects of the bridge functionality, including:
- Role management (e.g., DEFAULT_ADMIN_ROLE, GOVERNOR_ROLE)
- Bridge parameters (e.g., DISPUTE_PERIOD, FEE_RATE_MAX)
- Transaction statuses and proofs
- Fee-related information
The functions follow consistent naming conventions and provide a clear interface for interacting with the contract's read-only data.
Also applies to: 16-22, 23-29, 30-36, 37-43, 44-50, 51-57, 58-64, 65-71, 72-78, 124-132, 133-139, 140-152, 153-166, 167-173, 184-190, 204-272, 273-281, 282-291, 292-300, 311-320, 321-327, 328-334, 335-341, 416-424
79-122: State-changing functions are well-implemented and align with PR objectives.The ABI defines a comprehensive set of state-changing functions that cover the core operations of the bridge contract:
bridge: Initiates a bridge transactionclaim: Allows claiming of bridged fundsdispute: Handles dispute resolutionprove: Provides proof for a bridge transactionrefund: Implements refund functionality (aligning with the PR objective)relay: Relays a bridge transactionThe inclusion of role-based access control functions (
grantRole,revokeRole) suggests a secure approach to managing permissions. Therefundfunction specifically addresses the PR objective of implementing refund functionality for RFQ transactions.Also applies to: 174-183, 191-203, 342-351, 352-360, 361-369, 370-383, 384-393, 394-406, 407-415, 425-434
435-731: Events are well-defined and crucial for transparency.The ABI includes a comprehensive set of events that log important contract actions:
- Bridge-related events (e.g., BridgeDepositClaimed, BridgeDepositRefunded, BridgeProofDisputed)
- Role management events (RoleGranted, RoleRevoked)
- Parameter update events (ChainGasAmountUpdated, FeeRateUpdated)
These events are crucial for:
- Off-chain monitoring and indexing of contract activities
- Providing transparency for users and auditors
- Facilitating integration with external systems
The BridgeDepositRefunded event specifically supports the PR objective of implementing refund functionality. The appropriate use of indexing in event parameters allows for efficient filtering of logs.
Also applies to: 732-806
1-851: The FastBridge ABI is well-designed and aligns with PR objectives.This comprehensive ABI defines a robust interface for a cross-chain bridge contract. Key points:
- Core bridge functionalities (bridge, claim, refund) are well-represented.
- Role-based access control is implemented for security.
- Events provide transparency and support off-chain monitoring.
- Custom errors offer gas-efficient and informative error handling.
- The refund functionality aligns with the PR objective.
The ABI suggests a feature-rich and security-conscious contract design. However, it's crucial to note that while the ABI looks solid, the actual contract implementation should undergo thorough testing and auditing to ensure it behaves as expected and is free from vulnerabilities.
To ensure the contract behaves as expected, particularly regarding the new refund functionality, consider running the following verification:
packages/synapse-interface/components/_Transaction/_Transaction.tsx (7)
22-22: Importing 'useTxRefundStatus' HookThe new import statement correctly brings in the
useTxRefundStatushook, which is necessary for handling refunded transaction status.
34-34: Add 'routerAddress' to '_TransactionProps' InterfaceAdding
routerAddress: stringto the_TransactionPropsinterface ensures that the component receives the necessary router address prop for refund status checks.
39-39: Extend 'status' Prop with 'refunded' OptionIncluding
'refunded'in thestatusprop type extends the transaction status handling to cover refunded transactions.
54-54: Include 'routerAddress' in Component DestructuringDestructuring
routerAddressfrom the component props ensures that it's available within the component scope.
127-127: Update 'showTransactionSupport' Condition with 'refunded' StatusAdding
status === 'refunded'to the condition ensures that users receive appropriate support prompts for refunded transactions.
120-121: Confirm 'useBridgeTxUpdater' Accepts New ParametersVerify that the
useBridgeTxUpdaterhook acceptsisTxRevertedandisTxRefundedas parameters in the correct order.Run the following script to check the definition of
useBridgeTxUpdater:#!/bin/bash # Description: Confirm 'useBridgeTxUpdater' parameters rg --type javascript 'function useBridgeTxUpdater' -A 5 # Expected output should show 'isTxReverted' and 'isTxRefunded' as parameters.
86-86: Ensure 'isCheckTxForRefund' is Returned by 'calculateEstimatedTimeStatus'Verify that the
calculateEstimatedTimeStatusfunction returnsisCheckTxForRefundas expected. If not, the destructuring will result inundefined.Run the following script to confirm that
isCheckTxForRefundis included in the return statement:
| throw new Error(error) | ||
| } |
There was a problem hiding this comment.
Fix error rethrowing to properly capture error messages
Similarly, in the checkRFQTxBridgeStatus function, rethrowing an error with throw new Error(error) may lose important error details if error is an Error object. Rethrow the original error instead.
Apply this diff to fix the error rethrowing:
- throw new Error(error)
+ throw error📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| throw new Error(error) | |
| } | |
| throw error | |
| } |
| const getTxRefundStatus = async () => { | ||
| try { | ||
| const bridgeContract = await getRFQBridgeContract( | ||
| routerAddress, | ||
| chain?.id | ||
| ) | ||
|
|
||
| const status = await checkRFQTxBridgeStatus( | ||
| txId, | ||
| bridgeContract as Address, | ||
| chain?.id | ||
| ) | ||
|
|
||
| if (status === BridgeStatus.REFUNDED) { | ||
| setIsRefunded(true) | ||
| } | ||
| } catch (error) { |
There was a problem hiding this comment.
Ensure required parameters are defined before proceeding
In the getTxRefundStatus function, txId, chain?.id, and bridgeContract might be undefined, which could lead to runtime errors when calling checkRFQTxBridgeStatus. Add checks to ensure these values are defined before using them.
Apply this diff to add checks:
try {
+ if (!txId || !chain?.id) {
+ throw new Error('txId or chainId is undefined')
+ }
const bridgeContract = await getRFQBridgeContract(
routerAddress,
chain?.id
)
+ if (!bridgeContract) {
+ throw new Error('Bridge contract address is undefined')
+ }
const status = await checkRFQTxBridgeStatus(
txId,
bridgeContract as Address,
chain?.id
)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const getTxRefundStatus = async () => { | |
| try { | |
| const bridgeContract = await getRFQBridgeContract( | |
| routerAddress, | |
| chain?.id | |
| ) | |
| const status = await checkRFQTxBridgeStatus( | |
| txId, | |
| bridgeContract as Address, | |
| chain?.id | |
| ) | |
| if (status === BridgeStatus.REFUNDED) { | |
| setIsRefunded(true) | |
| } | |
| } catch (error) { | |
| const getTxRefundStatus = async () => { | |
| try { | |
| if (!txId || !chain?.id) { | |
| throw new Error('txId or chainId is undefined') | |
| } | |
| const bridgeContract = await getRFQBridgeContract( | |
| routerAddress, | |
| chain?.id | |
| ) | |
| if (!bridgeContract) { | |
| throw new Error('Bridge contract address is undefined') | |
| } | |
| const status = await checkRFQTxBridgeStatus( | |
| txId, | |
| bridgeContract as Address, | |
| chain?.id | |
| ) | |
| if (status === BridgeStatus.REFUNDED) { | |
| setIsRefunded(true) | |
| } | |
| } catch (error) { |
| throw new Error(error) | ||
| } |
There was a problem hiding this comment.
Fix error rethrowing to properly capture error messages
In the getRFQBridgeContract function, rethrowing an error using throw new Error(error) can cause issues if error is already an Error object. The Error constructor expects a string message, not an object. It's better to rethrow the original error to preserve the error information.
Apply this diff to fix the error rethrowing:
- throw new Error(error)
+ throw error📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| throw new Error(error) | |
| } | |
| throw error | |
| } |
| const isTxRefunded = useTxRefundStatus( | ||
| kappa, | ||
| routerAddress as Address, | ||
| originChain, | ||
| isCheckTxForRefund && | ||
| status === 'pending' && | ||
| bridgeModuleName === 'SynapseRFQ' | ||
| ) | ||
|
|
There was a problem hiding this comment.
Validate Parameters in 'useTxRefundStatus' Hook
Ensure that all parameters passed to useTxRefundStatus are correct and handle potential edge cases:
- Confirm that
kappaandrouterAddressare defined before usage. - Ensure
routerAddressis correctly cast toAddressand is a valid Ethereum address. - Verify the logical conditions in the check parameter accurately reflect when to check for a refund.
Consider adding null or undefined checks for kappa and routerAddress to prevent runtime errors. For example:
if (kappa && routerAddress) {
const isTxRefunded = useTxRefundStatus(
kappa,
routerAddress as Address,
originChain,
isCheckTxForRefund &&
status === 'pending' &&
bridgeModuleName === 'SynapseRFQ'
)
}
bigboydiamonds
changed the title
* update bl * remove global solidity extension settings * use monorepo support in global workspace only * - use Solidity extension for formatting *.sol files - use `forge fmt` as formatter in Solidity extension * REST API Improvements [SLT-179] (#3133) * fix swaptxinfo function * Updates test coverage command * migrating to using token addresses instead of symbols * fix linting errors * fixing swaptxinfocontroller * new tests and new functionality --------- Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> * Publish - @synapsecns/rest-api@1.0.75 - @synapsecns/synapse-interface@0.38.4 * fix harmony proxy (#3149) Co-authored-by: Trajan0x <trajan0x@users.noreply.github.com> * merging rfq indexer into monorepo [SLT-164] [SLT-176] (#3136) * merging rfq indexer into monorepo * nuke .env * fix commands * fix package name * test coverage script * rough pass at docs and some linting and fixes yarn * Upgrades wagmi & rainbowkit * indxer * Adds invisible but used packages * +recent-invalid-fills [SLT-188] * Moves wagmi to root * new endpoints and clean up linting --------- Co-authored-by: Trajan0x <trajan0x@users.noreply.github.com> Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> Co-authored-by: parodime <jordan@protochainresearch.com> * Publish - @synapsecns/synapse-interface@0.38.5 - @synapsecns/rfq-indexer-api@1.0.2 - @synapsecns/rfq-indexer@0.0.2 * Adds /destinationTokens route [SLT-204] (#3151) * Adds /destinationTokens route * ZeroAddress & NativeGasAddress * Adds test for native gas tokens * Checksums incoming token address params * Publish - @synapsecns/rest-api@1.0.76 * boba pause (#3150) * boba pause * only boba to txns * Publish - @synapsecns/synapse-interface@0.38.6 * fix(synapse-interface): Reorders validation to check existence first (#3156) * Reorders validation to check existence first * Removes duplicates * Publish - @synapsecns/rest-api@1.0.77 * Fix boba pause (#3158) * Publish - @synapsecns/synapse-interface@0.38.7 * update bl * feat(rest-api): Adds Swagger for api docs [SLT-205] (#3159) * Adds Swagger for api docs * Replace prepended verb Get routes with nouns * Adds dev flag for swagger serverUrl * Publish - @synapsecns/rest-api@1.1.0 - @synapsecns/synapse-interface@0.38.8 - @synapsecns/rfq-indexer-api@1.0.3 - @synapsecns/rfq-indexer@0.0.3 * Pulls version from package json (#3160) * Publish - @synapsecns/rest-api@1.1.1 * Require vs import due to file location (#3161) * Require vs import due to file location * Publish - @synapsecns/rest-api@1.1.2 * Prevent caching of api docs (#3162) * Publish - @synapsecns/rest-api@1.1.3 * feat(contracts-rfq): relay/prove/claim with different address [SLT-130] (#3138) * init. solidity ^. FbV2 relay/prove/claim overloads * +IFastBridgeV2, explicit address0 cast, func scope & inheritdoc fixes * pragma lock, contract relabel * feat: start scoping V2 tests * test: override relayer role scenarios, no longer enforced by V2 * test: finish the parity test * test: the management methods * test: dst chain scenarios * test: bridge * test: prove * test: claim * test: dispute * test: refund * test: bridge reverts * remove redundant extend. rearrange inherit list * revert 0.8.20 in favor of user (non-ws) setting --------- Co-authored-by: ChiTimesChi <88190723+ChiTimesChi@users.noreply.github.com> * Publish - FastBridge@0.4.0 * fix(promexporter): make spans better (#3164) * move the errors * [goreleaser] * fix v to w * changing native token address standard [SLT-210] (#3157) * changing native token address standard * fixing tests * normalizeNativeTokenAddress middleware, additional tests --------- Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> * Publish - @synapsecns/rest-api@1.1.4 * Refactoring rfq-indexer API and adding swagger docs [SLT-228] (#3167) * refactoring and adding swagger * remove testing scripts * fix typos and consistency with 404 errors * Publish - @synapsecns/rfq-indexer-api@1.0.4 * fix read mes (#3168) * Publish - @synapsecns/contracts-core@1.0.32 - FastBridge@0.4.1 - @synapsecns/solidity-devops@0.4.5 * fix(opbot): use submitter get tx status [SLT-158] (#3134) * use experimental logger to debug * fix lint * [goreleaser] * use submitter instead of client * [goreleaser] * [goreleaser] * fix(synapse-interface): Additional checks on screen [SLT-166] (#3152) * Additional checks on screen * Adds checks on chain/token changes * Publish - @synapsecns/synapse-interface@0.38.9 * feat(synapse-interface): confirm new price [SLT-150] (#3084) * add bridge quote history middleware * request user confirm changes when quoted price updates * add conditions for displaying confirm change state * track initial quote initializing confirm change state * specify output delta threshold * callback functions to handle initialize/accept/reset confirm changes flow * quote countdown timer animation to signal refresh * implement automatic refresh intervals * mouse move to refresh automatic intervals * add i8n translations for button text --------- Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> * Publish - @synapsecns/synapse-interface@0.39.0 * fix: formatted bridge fee amount (#3165) * Publish - @synapsecns/rest-api@1.1.5 * fix(contracts-rfq): CI workflows [SLT-245] (#3178) * fix: license, files * fix: package name * build: update solhint to latest * build: remove prettier dependencies * fix: solhint workflows * build: update solhint in other packages as well * chore: solhint rules, exceptions * fix: silence linter warnings in tests * chore: forge fmt * add variable to test linter CI * Revert "add variable to test linter CI" This reverts commit 0629309. * Publish - @synapsecns/contracts-core@1.0.33 - @synapsecns/contracts-rfq@0.5.0 - @synapsecns/solidity-devops@0.4.6 * feat(api): bridge limits [SLT-165] (#3179) * adds `/bridgeLimits` route, controller * fetch best sdk quote for min/max origin amounts * add tests * implement middleware to normalize addresses * adds swagger doc * Publish - @synapsecns/rest-api@1.2.0 * fix(contracts-rfq): limit the amount of solhint warnings [SLT-245] (#3182) * ci: limit the amount of solhint warnings * refactor: move the errors into the separate interface * refactor: errors imports in tests * Publish - @synapsecns/contracts-rfq@0.5.1 * ci: Solidity gas diff [SLT-259] (#3181) * ci: run tests w/o coverage first for better visibility * test: malform the test to check the adjusted workflow * Revert "test: malform the test to check the adjusted workflow" This reverts commit e7db6e1. * ci: add gas-diff workflow * try changing the contract to trigger gas diffs * retrigger the workflow * ci: provide the correct report path * ci: run on pull requests only * ci: save gas reports in monorepo root * Revert "ci: run on pull requests only" This reverts commit 0a01d60. * Revert "try changing the contract to trigger gas diffs" This reverts commit 91bc03e. * refactor: wrap if statement * refactor: exclude `solidity-devops` package in a more generic way * ci: run tests w/o coverage for `solidity-devops`, add comments * add generic comment to trigger `solidity-devops` workflows * Revert "add generic comment to trigger `solidity-devops` workflows" This reverts commit cc35a43. * Publish - @synapsecns/contracts-rfq@0.5.2 * fix(contracts-core): set very high gas limit for intensive tests [SLT-259] (#3186) * fix: set very high gas limit for intensive tests * ci: speed up solidity coverage * Publish - @synapsecns/contracts-core@1.0.34 * feat(rest-api): Adds validateRouteExists validation [SLT-260] (#3180) * Adds validateRouteExists validation * Remove timeouts for 400s * Publish - @synapsecns/rest-api@1.3.0 * add duplicate command warning (#3174) Co-authored-by: Trajan0x <trajan0x@users.noreply.github.com> * reduce solhint warnings on FbV2 (#3189) * reduce solhint warnings on FbV2 * fix whitespace * Publish - @synapsecns/contracts-rfq@0.5.3 * ci: solidity gas diff options [SLT-267] (#3193) * ci: ignore test files in gas diff report * add some changes to the test files * ci: define some options for gas-diff * try changing the contract to trigger gas diffs * Revert "try changing the contract to trigger gas diffs" This reverts commit 4504e3c. * Revert "add some changes to the test files" This reverts commit 7e7d6cb. * prove w/ tx id [SLT-181] (#3169) * prove w/ tx id SLT-181 * +proveOther tests, forge fmt * fmt * fmt * Publish - @synapsecns/contracts-rfq@0.5.4 * fix(sdk-router): disable ARB airdrop tests (#3195) * Publish - @synapsecns/rest-api@1.3.1 - @synapsecns/sdk-router@0.11.2 - @synapsecns/synapse-interface@0.39.1 - @synapsecns/widget@0.7.2 * Fixing issue for wallet integration [SLT-270] (#3194) * slight modification to graphql call * fixing explorer frontend as well * Publish - @synapsecns/explorer-ui@0.3.3 - @synapsecns/rest-api@1.3.2 * store relayer on relay [SLT-182] (#3170) * store relayer on relay [SLT-182] * +tests, zeroAddr check, fmt * Publish - @synapsecns/contracts-rfq@0.5.5 * Adjust text to trigger build (#3199) * Publish - @synapsecns/synapse-interface@0.39.2 * feat(synapse-interface): refund RFQ transaction [SLT-272] (#3197) * Txn transaction refund tracking * Update store to support tracking * Query FastBridge contract for `bridgeStatuses` to find refund status * Track bridge transaction `bridgeQuote.routerAddress` in store * Fetch FastBridge contract address when only provided router address * add translations --------- Co-authored-by: aureliusbtc <82057759+aureliusbtc@users.noreply.github.com> Co-authored-by: ChiTimesChi <88190723+ChiTimesChi@users.noreply.github.com> Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> Co-authored-by: Defi-Moses <Defi-Moses@users.noreply.github.com> Co-authored-by: trajan0x <83933037+trajan0x@users.noreply.github.com> Co-authored-by: Trajan0x <trajan0x@users.noreply.github.com> Co-authored-by: parodime <jordan@protochainresearch.com> Co-authored-by: abtestingalpha <104046418+abtestingalpha@users.noreply.github.com> Co-authored-by: abtestingalpha <abtestingalpha@users.noreply.github.com> Co-authored-by: parodime <parodime@users.noreply.github.com> Co-authored-by: vro <168573323+golangisfun123@users.noreply.github.com> Co-authored-by: ChiTimesChi <ChiTimesChi@users.noreply.github.com> Co-authored-by: bigboydiamonds <57741810+bigboydiamonds@users.noreply.github.com> Co-authored-by: bigboydiamonds <bigboydiamonds@users.noreply.github.com>
Description
Implements transaction status updates for when a RFQ transaction gets refunded after deadline passes. Builds on top of existing Transaction flow, adds another
'refunded'status tag to track behavior.95862fa: synapse-interface preview link
Summary by CodeRabbit
New Features
routerAddressproperty to various components for enhanced transaction tracking.Bug Fixes
Localization
Documentation