feat: new sending flow with UI#2175
Conversation
📝 WalkthroughWalkthroughThis update refactors transaction display logic, removes pending transaction handling, and introduces modular utilities for transaction details. It updates localization, enhances backend transaction import/export, and modifies process and wallet adapter functions for output control and error handling. Changes
Sequence Diagram(s)sequenceDiagram
participant UI
participant WalletManager
participant SpendWalletAdapter
participant WalletAdapter
UI->>WalletManager: import_transaction(tx_output_file)
WalletManager->>WalletAdapter: import_transaction(tx_output_file)
WalletAdapter->>WalletAdapter: Read JSON file
WalletAdapter->>WalletAdapter: Connect to gRPC client
WalletAdapter->>gRPC: ImportTransactionsRequest
gRPC-->>WalletAdapter: Import result
WalletAdapter-->>WalletManager: Result
WalletManager-->>UI: Success/Error
sequenceDiagram
participant UI
participant SpendWalletManager
participant SpendWalletAdapter
participant WalletManager
UI->>SpendWalletManager: send_one_sided_to_stealth_address(amount, destination, payment_id, view_wallet_manager)
SpendWalletManager->>SpendWalletAdapter: send_one_sided_to_stealth_address(amount, destination, payment_id, view_wallet_manager)
SpendWalletAdapter->>SpendWalletAdapter: execute_recovery_command()
SpendWalletAdapter->>SpendWalletAdapter: execute_sync_command()
SpendWalletAdapter->>SpendWalletAdapter: execute_send_one_sided_command()
SpendWalletAdapter->>SpendWalletAdapter: export_transaction(tx_id)
SpendWalletAdapter->>WalletManager: import_transaction(exported_tx_file)
WalletManager-->>SpendWalletAdapter: Import result
SpendWalletAdapter-->>SpendWalletManager: Result
SpendWalletManager-->>UI: Success/Error
Possibly related PRs
Suggested reviewers
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
npm warn config production Use ✨ 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:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 28
🔭 Outside diff range comments (2)
src/components/transactions/send/SendReview/SendReview.tsx (1)
10-12:⚠️ Potential issueRemove unused imports and parameters.
The linter correctly identifies several unused code elements that should be cleaned up:
Apply this diff to remove the unused imports and parameter:
-import { useEffect } from 'react'; import { SendStatus } from '@app/components/transactions/send/SendModal.tsx'; -import { useWalletStore } from '@app/store'; import { StatusHero } from '../../components/StatusHero/StatusHero';export function SendReview({ status, - setStatus, + setStatus: _setStatus, amount, address, message,Also applies to: 29-29
🧰 Tools
🪛 GitHub Check: Run linters
[warning] 12-12:
'useWalletStore' is defined but never used. Allowed unused vars must match /^_/u
[warning] 10-10:
'useEffect' is defined but never used. Allowed unused vars must match /^_/u🪛 GitHub Actions: Lint
[warning] 10-10: ESLint: 'useEffect' is defined but never used. Allowed unused vars must match /^_/u (@typescript-eslint/no-unused-vars)
[warning] 12-12: ESLint: 'useWalletStore' is defined but never used. Allowed unused vars must match /^_/u (@typescript-eslint/no-unused-vars)
src/components/transactions/history/helpers.ts (1)
3-13: 🛠️ Refactor suggestionConsider using a hook for store access to maintain React reactivity.
The
formatTimeStampfunction directly callsuseConfigUIStore.getState()which bypasses React's reactivity system. This means components using this function won't re-render when the language settings change.Consider refactoring to use the store hook within components instead:
-function formatTimeStamp(timestamp: number): string { - const appLanguage = useConfigUIStore.getState().application_language; - const systemLang = useConfigUIStore.getState().should_always_use_system_language; +function formatTimeStamp(timestamp: number, appLanguage?: string, systemLang?: boolean): string { return new Date(timestamp * 1000)?.toLocaleString(systemLang ? undefined : appLanguage, { month: 'short', day: '2-digit', hourCycle: 'h23', hour: 'numeric', minute: 'numeric', }); }Then in components:
const appLanguage = useConfigUIStore(s => s.application_language); const systemLang = useConfigUIStore(s => s.should_always_use_system_language); const formattedTime = formatTimeStamp(item.timestamp, appLanguage, systemLang);
🧹 Nitpick comments (6)
src/components/transactions/send/SendModal.tsx (1)
75-75: Transaction refresh approach ensures data consistency.Replacing
addPendingTransaction(payload)withawait refreshTransactions()provides better data consistency by fetching the complete transaction state from the backend instead of optimistically updating the UI state.However, consider the performance impact of refreshing all transactions after each send operation, especially for users with large transaction histories.
The current implementation from
src/store/actions/walletStoreActions.ts(lines 56-59) fetches transactions with a limit based on existing count, which helps mitigate performance concerns by maintaining a reasonable fetch size.src-tauri/src/process_utils.rs (1)
57-66: Consider extracting the conditional stdio logic for DRY compliance.The stdout/stderr conditional logic is duplicated between Windows and non-Windows sections.
Consider extracting the stdio configuration to reduce duplication:
+ let stdout = if allow_output { + std::process::Stdio::piped() + } else { + std::process::Stdio::null() + }; + let stderr = if allow_output { + std::process::Stdio::piped() + } else { + std::process::Stdio::null() + }; + #[cfg(not(target_os = "windows"))] { Ok(tokio::process::Command::new(file_path) .args(args) .current_dir(current_dir) .envs(envs.cloned().unwrap_or_default()) .stdout(stdout) .stderr(stderr) .kill_on_drop(true) .spawn()?) }This approach eliminates the duplication while maintaining the same functionality.
src/utils/getTxStatus.ts (1)
47-70: Simplify conditional logic and improve readability.The nested conditionals and repetitive type checking can be simplified for better maintainability.
Consider this refactor to improve readability:
export function getTxTitle(transaction: TransactionInfo): string { const itemType = getTxTypeByStatus(transaction); const txMessage = transaction.payment_id; const statusTitleKey = getTxStatusTitleKey(transaction); - const statusTitle = i18n.t(`common:${statusTitleKey}`); + const statusTitle = statusTitleKey ? i18n.t(`common:${statusTitleKey}`) : ''; const typeTitle = itemType === 'unknown' ? TransactionDirection[transaction.direction] : i18n.t(`common:${itemType}`); + // Priority 1: Show block height for mined transactions if (itemType === 'mined' && transaction.mined_in_block_height) { return `${i18n.t('sidebar:block')} #${transaction.mined_in_block_height}`; } - if (txMessage && !txMessage.includes('<No message>')) { - if (statusTitleKey !== 'complete') { - return `${txMessage} | ${statusTitle}`; - } - return txMessage; - } + const hasValidMessage = txMessage && !txMessage.includes('<No message>'); + const isComplete = statusTitleKey === 'complete'; - if (statusTitleKey !== 'complete') { - return `${typeTitle} | ${statusTitle}`; - } - return i18n.t(`common:${itemType}`); + // Priority 2: Show message with status (if not complete) + if (hasValidMessage) { + return isComplete ? txMessage : `${txMessage} | ${statusTitle}`; + } + + // Priority 3: Show type with status or just type + return isComplete ? i18n.t(`common:${itemType}`) : `${typeTitle} | ${statusTitle}`; }src/components/transactions/history/details/getListEntries.ts (1)
50-53: Consider omitting the raw status value from the UI.Displaying the raw numeric status value (e.g., "14", "12") in
valueRightmay confuse users. The translated status text should be sufficient.if (key === 'status') { const tKey = getTxStatusTitleKey(transaction); - return { value: i18n.t(`common:${tKey}`), valueRight: value }; + return { value: i18n.t(`common:${tKey}`) }; }src-tauri/src/spend_wallet_adapter.rs (2)
184-190: Clever use of fake base node address to prevent broadcasting.Using an allocated but unused port ensures the wallet cannot establish a connection to broadcast the transaction. This forces the transaction to remain local for export. Consider adding a comment explaining this intentional behavior for future maintainers.
async fn execute_send_one_sided_command( &self, amount: &str, destination: &str, payment_id: Option<String>, ) -> Result<Option<String>, Error> { - // Allocate an unused port to ensure the transaction is not successfully broadcasted. - // This is intentional as we want to export the transaction to the view wallet instead. + // IMPORTANT: We intentionally use a fake base node address with an unused port to prevent + // the transaction from being broadcasted. This ensures the transaction remains local + // so we can export it and import it into the view wallet for proper handling. let fake_base_node_public_key = self.get_base_node_public_key_hex();
333-336: Remove unnecessary async from erase_related_data method.The method only performs synchronous operations and doesn't need to be async.
-pub async fn erase_related_data(&self) -> Result<(), Error> { +pub fn erase_related_data(&self) -> Result<(), Error> { std::fs::remove_dir_all(self.get_working_dir())?; Ok(()) }Note: You'll also need to update the calls to this method to remove
.await:
- Line 97:
let _unused = self.erase_related_data();- Line 136:
self.erase_related_data()?;
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
src-tauri/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (55)
public/locales/af/common.json(2 hunks)public/locales/af/wallet.json(1 hunks)public/locales/cn/common.json(2 hunks)public/locales/cn/wallet.json(1 hunks)public/locales/de/common.json(2 hunks)public/locales/de/wallet.json(1 hunks)public/locales/en/common.json(2 hunks)public/locales/en/wallet.json(2 hunks)public/locales/fr/common.json(2 hunks)public/locales/fr/wallet.json(1 hunks)public/locales/hi/common.json(2 hunks)public/locales/hi/wallet.json(1 hunks)public/locales/id/common.json(2 hunks)public/locales/id/wallet.json(1 hunks)public/locales/ja/common.json(2 hunks)public/locales/ja/wallet.json(1 hunks)public/locales/ko/common.json(2 hunks)public/locales/ko/wallet.json(1 hunks)public/locales/pl/common.json(2 hunks)public/locales/pl/wallet.json(1 hunks)public/locales/ru/common.json(2 hunks)public/locales/ru/wallet.json(1 hunks)public/locales/tr/common.json(2 hunks)public/locales/tr/wallet.json(1 hunks)src-tauri/Cargo.toml(3 hunks)src-tauri/src/commands.rs(1 hunks)src-tauri/src/events_manager.rs(1 hunks)src-tauri/src/gpu_miner.rs(1 hunks)src-tauri/src/node/node_adapter.rs(1 hunks)src-tauri/src/node/remote_node_adapter.rs(2 hunks)src-tauri/src/process_adapter.rs(3 hunks)src-tauri/src/process_utils.rs(1 hunks)src-tauri/src/spend_wallet_adapter.rs(4 hunks)src-tauri/src/spend_wallet_manager.rs(2 hunks)src-tauri/src/wallet_adapter.rs(5 hunks)src-tauri/src/wallet_manager.rs(1 hunks)src/components/AdminUI/groups/SwapsGroup.tsx(1 hunks)src/components/transactions/history/ExpandedItem.tsx(0 hunks)src/components/transactions/history/HistoryList.tsx(5 hunks)src/components/transactions/history/ListItem.tsx(3 hunks)src/components/transactions/history/details/TransactionDetails.tsx(1 hunks)src/components/transactions/history/details/getListEntries.ts(1 hunks)src/components/transactions/history/details/styles.ts(1 hunks)src/components/transactions/history/helpers.ts(1 hunks)src/components/transactions/send/SendForm.tsx(1 hunks)src/components/transactions/send/SendModal.tsx(2 hunks)src/components/transactions/send/SendReview/SendReview.tsx(1 hunks)src/components/transactions/types.ts(2 hunks)src/components/transactions/wallet/wallet.styles.ts(1 hunks)src/store/actions/appConfigStoreActions.ts(0 hunks)src/store/actions/walletStoreActions.ts(1 hunks)src/store/useBlockchainVisualisationStore.ts(3 hunks)src/store/useWalletStore.ts(1 hunks)src/types/transactions.ts(1 hunks)src/utils/getTxStatus.ts(1 hunks)
💤 Files with no reviewable changes (2)
- src/store/actions/appConfigStoreActions.ts
- src/components/transactions/history/ExpandedItem.tsx
🧰 Additional context used
🧠 Learnings (3)
src/components/transactions/history/HistoryList.tsx (1)
Learnt from: peps
PR: tari-project/universe#2056
File: src/components/transactions/history/HistoryList.tsx:55-63
Timestamp: 2025-05-07T11:46:20.991Z
Learning: The HistoryListItem component in src/components/transactions/history/ListItem.tsx no longer uses a triple-click handler or maintains internal expansion state. Expansion is now handled at a higher level using the setDetailsItem prop to show details in a separate view.
src/components/transactions/history/details/TransactionDetails.tsx (1)
Learnt from: peps
PR: tari-project/universe#2056
File: src/components/transactions/history/HistoryList.tsx:55-63
Timestamp: 2025-05-07T11:46:20.991Z
Learning: The HistoryListItem component in src/components/transactions/history/ListItem.tsx no longer uses a triple-click handler or maintains internal expansion state. Expansion is now handled at a higher level using the setDetailsItem prop to show details in a separate view.
src/components/transactions/history/ListItem.tsx (1)
Learnt from: peps
PR: tari-project/universe#2056
File: src/components/transactions/history/HistoryList.tsx:55-63
Timestamp: 2025-05-07T11:46:20.991Z
Learning: The HistoryListItem component in src/components/transactions/history/ListItem.tsx no longer uses a triple-click handler or maintains internal expansion state. Expansion is now handled at a higher level using the setDetailsItem prop to show details in a separate view.
🧬 Code Graph Analysis (8)
src-tauri/src/wallet_manager.rs (1)
src-tauri/src/wallet_adapter.rs (3)
import_transaction(100-140)from(663-678)from(704-711)
src/store/actions/walletStoreActions.ts (1)
src/store/useWalletStore.ts (1)
useWalletStore(46-48)
src/store/useBlockchainVisualisationStore.ts (1)
src/store/useAppConfigStore.ts (1)
useConfigUIStore(84-86)
src/components/transactions/history/details/TransactionDetails.tsx (6)
src/types/app-status.ts (1)
TransactionInfo(73-87)src/hooks/helpers/useCopyToClipboard.ts (1)
useCopyToClipboard(4-30)src/components/transactions/history/details/getListEntries.ts (1)
getListEntries(68-78)src/components/TransactionModal/TransactionModal.tsx (1)
TransactionModal(18-62)src/components/transactions/history/details/styles.ts (1)
Wrapper(3-7)src/components/transactions/components/StatusList/StatusList.tsx (1)
StatusList(19-41)
src/components/transactions/history/details/getListEntries.ts (6)
src/types/app-status.ts (1)
TransactionInfo(73-87)src/store/useMiningStore.ts (1)
useMiningStore(33-35)src/components/transactions/components/StatusList/StatusList.tsx (1)
StatusListEntry(6-13)src/components/transactions/history/helpers.ts (1)
formatTimeStamp(14-14)src/utils/getTxStatus.ts (2)
getTxTitle(47-70)getTxStatusTitleKey(40-46)src/utils/formatters.ts (1)
formatNumber(81-103)
src/utils/getTxStatus.ts (2)
src/types/app-status.ts (1)
TransactionInfo(73-87)src/components/transactions/types.ts (1)
TransationType(4-4)
src/components/transactions/send/SendModal.tsx (1)
src/store/actions/walletStoreActions.ts (1)
refreshTransactions(56-59)
src-tauri/src/spend_wallet_adapter.rs (3)
src-tauri/src/wallet_adapter.rs (3)
from(663-678)from(704-711)new(73-90)src-tauri/src/spend_wallet_manager.rs (1)
new(50-57)src-tauri/src/port_allocator.rs (1)
assign_port_with_fallback(73-93)
🪛 GitHub Actions: Lint
src/components/transactions/send/SendReview/SendReview.tsx
[warning] 10-10: ESLint: 'useEffect' is defined but never used. Allowed unused vars must match /^_/u (@typescript-eslint/no-unused-vars)
[warning] 12-12: ESLint: 'useWalletStore' is defined but never used. Allowed unused vars must match /^_/u (@typescript-eslint/no-unused-vars)
[warning] 29-29: ESLint: 'setStatus' is defined but never used. Allowed unused args must match /^_/u (@typescript-eslint/no-unused-vars)
src/store/useBlockchainVisualisationStore.ts
[error] 15-15: Prettier formatting error: Delete newline (prettier/prettier).
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: tauri-build
- GitHub Check: cargo checks (fmt, clippy, check)
🔇 Additional comments (40)
src/components/transactions/history/details/styles.ts (1)
1-7: Styled-component Wrapper looks goodThe new
Wrappercomponent correctly applies a flex layout with a scrollable max-height constraint for transaction details content. This aligns with the intended modal behavior and ensures usability for lengthy content.public/locales/en/wallet.json (1)
23-27: Localization updates for send flowThe new
"broadcast"key and the updated"completed-text"accurately reflect the revised UX copy in English. No issues found.public/locales/en/common.json (1)
6-6: Added new status keys in English localeThe new
"complete","failed", and"pending"keys have been correctly inserted with English values in the common locale.Also applies to: 13-13, 23-23
src/components/transactions/wallet/wallet.styles.ts (1)
8-8: Updated max-height clamp is validThe change to
max-height: clamp(10vh, 600px, 55vh);appropriately increases the allowable height for the wallet wrapper. The clamp parameters correctly enforce minimum and maximum viewport proportions with a reasonable ideal fallback.src/components/transactions/types.ts (1)
2-2: Clean interface refactor for transaction direction handling.The addition of
TransactionDirectionimport and the property change fromtypetodirectioninBaseItemPropsaligns well with the broader refactor toward direction-based transaction handling. This semantic improvement should make the code more intuitive.Also applies to: 15-15
src/components/transactions/send/SendForm.tsx (1)
44-48: Good addition of zero amount validation.The explicit check for zero amounts with early return is a solid defensive programming practice. It prevents invalid transactions and provides immediate feedback without unnecessary async validation calls.
src-tauri/src/node/node_adapter.rs (1)
103-103:Details
❓ Verification inconclusive
Verify the new gRPC field name exists.
The field name change from
randomx_estimated_hash_ratetomonero_randomx_estimated_hash_rateappears to be related to the Tari dependency upgrades. Please ensure this field name exists in the updated gRPC response structure to avoid runtime errors.
🏁 Script executed:
#!/bin/bash # Search for the new field name in the codebase to verify its usage rg "monero_randomx_estimated_hash_rate" --type rust # Also search for any remaining references to the old field name rg "randomx_estimated_hash_rate" --type rustLength of output: 322
Confirm updated gRPC field in BaseNodeStatus
I’ve searched the Rust code and confirmed that only
res.monero_randomx_estimated_hash_rateis referenced—there are no remaining mentions ofrandomx_estimated_hash_rate. To avoid runtime mismatches, please verify against your gRPC definitions:
- Ensure the
BaseNodeStatusmessage in the updated.protofile definesmonero_randomx_estimated_hash_rate.- Confirm that your generated Rust client stubs (via
tonic::include_proto!or equivalent) include this new field.src-tauri/src/events_manager.rs (1)
57-58: LGTM! Typo fix improves code readability.The variable name correction from
in_memoery_configtoin_memory_configfixes a typo and ensures consistency with the actual field namein_memory_configfrom the state.src/components/transactions/send/SendReview/SendReview.tsx (1)
65-65: Status label change aligns with new transaction flow.The change from displaying "completed" to "broadcast" when status is not 'processing' correctly reflects the updated transaction status terminology mentioned in the AI summary.
src-tauri/src/gpu_miner.rs (1)
217-218: LGTM! Function call updated to match new signature.The addition of the
falseparameter correctly adapts to the updatedlaunch_child_processfunction signature that now includes anallow_outputparameter. Setting it tofalseis appropriate for the GPU detection process where output capture is not needed.src/components/transactions/send/SendModal.tsx (1)
10-10: Import updated to align with new transaction handling architecture.The change from
addPendingTransactiontorefreshTransactionscorrectly reflects the architectural shift away from managing individual pending transactions in the UI state.src-tauri/src/commands.rs (1)
1881-1881: LGTM! Parameter addition supports transaction import/export flow.The addition of
&state.wallet_managerparameter enables the spend wallet to export transactions and import them into the view wallet manager, as described in the AI summary. This change is well-coordinated with the broader transaction flow enhancements.src/store/useBlockchainVisualisationStore.ts (3)
12-13: Good refactoring: removing pending transaction dependency.The removal of
refreshPendingTransactionsand addition ofuseConfigUIStorealigns well with the broader changes to simplify transaction state management and add visual mode configuration.
73-77: Excellent implementation of visual mode gating.The conditional check for
visualModeEnabledproperly gates animation logic, ensuring animations only trigger when bothcanAnimateand visual mode are enabled. This provides users with fine-grained control over visual features.
98-99: Consistent visual mode gating in handleFail.The implementation matches the pattern used in
handleWin, ensuring consistent behavior across both success and failure scenarios. This maintains a cohesive user experience.src/store/actions/walletStoreActions.ts (1)
84-84: Good simplification: removing pending transaction complexity.The direct assignment of the balance state is cleaner and aligns with the broader effort to remove pending transaction tracking from the wallet store. This simplification improves code maintainability while the
calculated_balancecomputation remains correct.src-tauri/src/wallet_manager.rs (1)
189-200: Well-implemented transaction import method.The new
import_transactionmethod follows established patterns in the codebase:
- Proper async/await usage
- Consistent error handling with wallet state validation
- Appropriate delegation to the adapter layer
- Good error message for wallet not started scenario
The integration with the existing
WalletAdapter::import_transactionmethod (as shown in relevant code snippets) creates a clean separation of concerns.src-tauri/Cargo.toml (1)
42-43:Details
❓ Verification inconclusive
Verify compatibility for major version upgrades.
The upgrade from Tari crates v1.18.0-rc.0 to v3.0.0 represents a significant jump that skips major versions. Similarly, tonic upgraded from 0.12.3 to 0.13.1. These changes need verification for breaking API changes and compatibility issues.
Please verify the compatibility and check for breaking changes:
Additionally, please search the web for version compatibility information:
Also applies to: 62-70, 97-97
🏁 Script executed:
#!/bin/bash # Description: Check for breaking changes and API compatibility in the upgraded dependencies echo "Checking for potential breaking changes in Tari crates and tonic..." # Search for usage of potentially affected APIs echo "=== Searching for minotari_node_grpc_client usage ===" rg -A 3 "minotari_node_grpc_client::" --type rust echo "=== Searching for minotari_wallet_grpc_client usage ===" rg -A 3 "minotari_wallet_grpc_client::" --type rust echo "=== Searching for tonic usage ===" rg -A 3 "tonic::" --type rust echo "=== Searching for tari_common usage ===" rg -A 3 "tari_common::" --type rust echo "=== Searching for tari_core usage ===" rg -A 3 "tari_core::" --type rust echo "=== Checking for deprecated patterns or imports ===" rg -A 2 -B 2 "deprecated|DEPRECATED" --type rustLength of output: 14331
🌐 Web query:
What are the breaking changes between Tari v1.18.0-rc.0 and v3.0.0? Are there any security vulnerabilities in tonic 0.13.1?💡 Result:
Breaking Changes Between Tari v1.18.0-rc.0 and v3.0.0
The provided search results do not contain a comprehensive changelog directly contrasting Tari v1.18.0-rc.0 with v3.0.0. However, indications from the Tari repository's changelog and related documentation suggest several notable breaking changes in recent major releases:
- Database Format/Wallet Type: There was a breaking change and subsequent hotfix related to how wallet type information is stored in the database. This change required special handling and could impact users upgrading across releases that made schema or serialization adjustments[1].
- ByteArray Trait Changes: In Tari utilities, breaking changes were made to the
ByteArraytrait, including a rename of thefrom_bytesfunction tofrom_canonical_bytes. This affects API consumers and implementers relying on that trait[3].- Protocol and Schema Evolution: According to Tari's RFCs, version numbers must increment for any changes to the blockchain schema or validation rules, which is typical in major version changes[2]. This means that v3.0.0 may involve chain-level incompatibilities (e.g., changes to consensus, block structure, or transaction validation).
- Wallet and Node Configuration: The process for setting up nodes and wallets—including the introduction of additional gRPC methods for monitoring and submission—has evolved, often introducing incompatible configuration shifts[4].
- Library Upgrades: There is an emphasis on keeping dependencies aligned with upstream changes, which may include breaking API changes or new minimum requirements for Rust versions or related tools.
Because the changelog or documentation explicitly enumerating all breaking changes for the jump from v1.18.0-rc.0 to v3.0.0 is not available in the provided results, users are advised to consult both the main Tari repository and the specific migration/upgrade notes for each service or library to ensure compatibility[1][3][2][4].
Security Vulnerabilities in tonic 0.13.1
No explicit security vulnerabilities have been reported for tonic 0.13.1 in the search results[8][6]. Key points from the references:
- The tonic 0.13.1 release documentation and changelog do not mention any security advisories or vulnerability patches for this version[8][6].
- Recent releases and changelogs for tonic have occasionally contained updates related to the hyper and prost ecosystems (e.g., in 0.12.x and 0.13.x), but no vulnerabilities are noted for 0.13.1[6].
- No advisories or vulnerability warnings are provided on popular open-source vulnerability databases for related tonic libraries[9].
Based on available information, tonic 0.13.1 does not have known published security vulnerabilities as of now[8][6].
Summary Table:
Topic Finding Tari Major Changes Breaking database format changes, ByteArray trait changes, protocol/schema updates, wallet config. tonic 0.13.1 Security No known or reported vulnerabilities as of May 2025. If you require a line-by-line breakdown of Tari's breaking changes, consult the Tari changelog and migration documentation. For tonic, it's prudent to monitor the official changelog and Rust advisories for updates.
Citations:
- 1: https://github.com/tari-project/tari/blob/development/changelog-nextnet.md
- 2: https://rfc.tari.com/print
- 3: https://github.com/tari-project/tari_utilities/blob/main/CHANGELOG.md
- 4: https://www.tari.com/lessons/09_adding_tari_to_your_exchange
- 5: https://www.scribd.com/document/453965681/10-1007-978-981-15-1518-7-pdf
- 6: https://github.com/hyperium/tonic/blob/master/CHANGELOG.md
- 7: https://cybersecuritynews.com/ios-18-32-vulnerabilities/
- 8: https://docs.rs/crate/tonic/latest
- 9: https://deps.rs/crate/tonic-reflection/0.12.3
- 10: https://security.snyk.io/package/npm/tonic-ui/1.2.13
Double-check breaking changes for Tari v3.0.0 upgrade
We inspected all uses of the upgraded Tari gRPC clients,
tonic,tari_commonandtari_core. No immediate import errors or new deprecations appeared, but the jump from v1.18.0-rc.0 to v3.0.0 carries several known breaking changes that aren’t auto-detectable:• Database format / wallet schema migrations (ensure your on-disk wallet/data formats are upgraded or migrated).
•ByteArraytrait renames (from_bytes→from_canonical_bytes).
• Protocol/schema evolutions (chain-level changes to block/transaction structures).
• gRPC surface/API changes (added, removed or renamed methods in the node and wallet clients).
• Configuration shifts in node/wallet setup (new required fields or tightened validation).For tonic 0.13.1, no published security vulnerabilities are known.
Please manually verify:
- All gRPC client calls in
src-tauri/src/wallet_adapter.rs,node_adapter.rs,remote_node_adapter.rs, etc., still compile and match the new method signatures.- Any direct uses of
ByteArrayor related trait functions are updated.- Run the full test suite and end-to-end wallet/node integration to catch runtime mismatches.
src-tauri/src/node/remote_node_adapter.rs (1)
230-238: LGTM! Well-implemented null process method.The
start_and_wait_for_outputmethod implementation is correct for a null process instance. It properly:
- Calls the existing
start()method- Awaits the
wait()method for completion- Returns the exit code with empty output vectors (appropriate for a remote node that doesn't generate local output)
This follows the expected pattern for coordinating process management with output capture across the codebase.
src-tauri/src/spend_wallet_manager.rs (1)
76-98:Details
✅ Verification successful
Good error handling improvement with cleanup on failure.
The changes enhance the method with:
- Additional
view_wallet_managerparameter to enable transaction export/import flow- Proper error handling that calls
erase_related_data()for cleanup on failure- Maintains the same return semantics
Please verify that all callers have been updated for the new method signature:
🏁 Script executed:
#!/bin/bash # Description: Verify all calls to send_one_sided_to_stealth_address have been updated echo "=== Searching for calls to send_one_sided_to_stealth_address ===" rg -A 5 "send_one_sided_to_stealth_address" --type rust echo "=== Checking for potential compilation issues ===" ast-grep --pattern 'send_one_sided_to_stealth_address($_, $_, $_)'Length of output: 3739
All invocations updated for the new signature – no further action required.
Verification summary:
- Adapter definition in
src-tauri/src/spend_wallet_adapter.rsnow acceptsview_wallet_manager.- Command in
src-tauri/src/commands.rspasses&state.wallet_manageras the fourth argument.- No remaining calls with only three parameters (confirmed via
ast-grep).src/components/transactions/history/HistoryList.tsx (3)
23-23: Excellent refactoring to remove pending transaction logic.The changes are well-executed and consistent:
- Clean removal of
pendingTransactionsandcombinedTransactionslogic- Consistent use of
transactionsarray throughout the component- Proper update of memoization dependencies
- Maintains all existing functionality (infinite scroll, loading states, new transaction badges)
The refactoring aligns perfectly with the goal of streamlining the transaction history to show only confirmed transactions.
Also applies to: 32-77, 95-95
106-111: Enhanced transaction details with new TransactionDetails component.The replacement of
ItemExpandwithTransactionDetailsprovides improved functionality including triple-click hidden details toggle and copy-to-clipboard features as mentioned in the AI summary.
14-14:Details
✅ Verification successful
Verify the new TransactionDetails component import.
The component now imports
TransactionDetailsinstead of the previousItemExpand. Please ensure this component exists and has the expected interface.
🏁 Script executed:
#!/bin/bash # Description: Verify the TransactionDetails component exists and check its interface echo "=== Checking if TransactionDetails component exists ===" fd "TransactionDetails.tsx" src/ echo "=== Checking the component interface ===" cat src/components/transactions/history/details/TransactionDetails.tsx | head -50Length of output: 2533
TransactionDetails component verified
The
TransactionDetailscomponent is present atsrc/components/transactions/history/details/TransactionDetails.tsxand exports the expected props interface:
item: TransactionInfoexpanded: booleanhandleClose: () => voidImport and usage in
HistoryList.tsxare correct—no further action required.src-tauri/src/process_utils.rs (1)
25-41: LGTM! Clean implementation of output control.The addition of the
allow_outputparameter is well-implemented with clear conditional logic for controlling stdout/stderr piping. The implementation maintains consistency across both Windows and non-Windows platforms.src/components/transactions/history/details/TransactionDetails.tsx (2)
26-37: LGTM! Well-implemented triple-click handler with proper cleanup.The triple-click detection logic is correctly implemented with proper timeout cleanup and state management. The 300ms timeout is appropriate for detecting rapid clicks.
48-50:Details
✅ Verification successful
Verify that TransactionInfo can be safely stringified.
The
JSON.stringify(item)call assumes theTransactionInfoobject doesn't contain circular references or non-serializable properties.Let me verify the TransactionInfo structure to ensure safe JSON serialization:
🏁 Script executed:
#!/bin/bash # Description: Verify TransactionInfo type definition and usage to ensure it's safe for JSON.stringify # Expected: TransactionInfo should have simple, serializable properties # Check the TransactionInfo interface definition rg -A 20 "interface TransactionInfo" --type ts # Check for any complex nested objects or potential circular references ast-grep --pattern 'interface TransactionInfo { $$$ }'Length of output: 1879
TransactionInfo is safe to JSON.stringify
I verified the
TransactionInfodefinition insrc/types/app-status.ts—all properties are primitives (number,string,boolean, optionalnumber). There are no methods, nested objects, or circular refs, soJSON.stringify(item)is safe as-is.src/components/transactions/history/ListItem.tsx (4)
23-24: LGTM! Proper import of new utility functions.The imports correctly reference the new centralized transaction utilities and the TransactionDirection enum, aligning with the refactoring effort to centralize transaction logic.
71-77: LGTM! Consistent use of new utility functions.The refactoring correctly replaces the old helper functions with the new centralized utilities
getTxTypeByStatusandgetTxTitle, maintaining the same functionality while following the new architecture.
88-88: LGTM! Proper use of direction property.The change from passing a computed type to using the transaction's
directionproperty directly is cleaner and aligns with the new direction-based approach using theTransactionDirectionenum.
26-32:Details
❓ Verification inconclusive
Verify the truncation length change from 30 to 26.
The title truncation length was reduced from 30 to 26 characters. Please confirm this change is intentional and aligns with UI design requirements.
Let me check if this change is documented or if there are related UI layout changes:
🏁 Script executed:
#!/bin/bash # Description: Check for any UI layout changes or design specifications related to title truncation # Expected: Find context for the truncation length change # Look for related truncation changes or comments rg -i "truncate|26|30" --type tsx --type ts -A 3 -B 3 # Check for any CSS or styling changes that might affect title display fd "ListItem.styles" --exec cat {}Length of output: 5150
Verify Title Truncation Change
The threshold was reduced from 30 to 26 characters, but there’s no accompanying update in styles or documentation. Please confirm this aligns with the UI design spec.• src/components/transactions/history/ListItem.tsx (lines 26–32)
–displayTitle = title.length > 26 ? truncateMiddle(title, 8) : title
• No references to “26” or rationale found in ListItem.styles.ts or elsewheresrc-tauri/src/process_adapter.rs (2)
141-144: LGTM: Well-designed trait method signature.The new async method signature is consistent with the existing trait pattern and provides a clear interface for process execution with output capture.
197-197:Details
✅ Verification successful
Verify consistency with process_utils.rs signature.
The change to explicitly pass
falsefor output capture aligns with the new parameter mentioned in the AI summary. Ensure this matches the updatedlaunch_child_processfunction signature.
🏁 Script executed:
#!/bin/bash # Description: Verify the launch_child_process function signature and its usage # Expected: Function should accept boolean parameter for output control ast-grep --pattern 'fn launch_child_process($$$, $ALLOW_OUTPUT: $_) $$$'Length of output: 74
🏁 Script executed:
#!/bin/bash # Search for the signature of launch_child_process in the codebase rg "fn launch_child_process" -n rg "launch_child_process" -nLength of output: 567
🏁 Script executed:
#!/bin/bash # Display the signature of `launch_child_process` in process_utils.rs rg -n 'pub fn launch_child_process' -A5 src-tauri/src/process_utils.rsLength of output: 272
Reviewed
launch_child_processSignature and Usage
All calls tolaunch_child_processin process_adapter.rs now correctly pass the newallow_output: boolparameter (false), matching its definition in process_utils.rs (file_path, current_dir, envs, args, allow_output: bool). No further changes required.src/store/useWalletStore.ts (1)
3-3: LGTM: Clean removal of unused import.The removal of
setWalletBalanceimport aligns with the broader refactor to eliminate pending transaction handling from the wallet store. The remainingrefreshTransactionsimport is appropriate for the simplified transaction management approach.src/types/transactions.ts (2)
1-6: LGTM: Good documentation and enum organization.The comment about syncing with
tari.rpc.rsis helpful for maintainability. MovingTransactionDirectionto the top and explicitly exporting it improves code organization and discoverability.
8-24:Details
❓ Verification inconclusive
Verify enum values align with backend definitions.
The expanded
TransactionStatusenum includes many new values. Ensure these numeric values exactly match the backend enum definitions to prevent runtime issues.
🏁 Script executed:
#!/bin/bash # Description: Search for the backend enum definition to verify alignment # Expected: Find tari.rpc.rs file with matching enum values fd -e rs -x grep -l "TransactionStatus\|enum.*Status" {} \; | head -5 ast-grep --pattern 'enum $_ { $$$ Completed = $_, $$$ }'Length of output: 1191
Verify TransactionStatus enum values match backend definitions
I was unable to locate a corresponding
TransactionStatusenum in the Rust code here, so please confirm that the numeric values insrc/types/transactions.tsexactly mirror those defined in your backend (e.g. gRPC/RPC proto or native Rust enum). A mismatch could cause subtle runtime bugs.• Check the source of truth for
TransactionStatusin the backend (e.g. .proto file or Rust crate)
• Ensure each status name and its integer value (0–14) align perfectly
• Update either side if there are any discrepanciessrc-tauri/src/wallet_adapter.rs (2)
100-140: Well-structured transaction import implementation.The method has excellent error handling with detailed logging at each step, making debugging easier. The JSON array wrapping is appropriate if the gRPC API expects multiple transactions.
198-198:Details
❓ Verification inconclusive
Verify the payment ID field name change is compatible with the gRPC API.
The field name has been changed from
tx.payment_idtotx.user_payment_id. Please ensure this change is compatible with the current gRPC API version and that all transactions have this field populated.Run the following script to check if there are any other references to the old field name that might need updating:
Also applies to: 266-266
🏁 Script executed:
#!/bin/bash # Description: Search for any remaining references to the old payment_id field in transaction contexts # Search for payment_id references in Rust files that might be related to transactions rg -A 3 -B 3 'tx\.payment_id|transaction.*payment_id' --type rust # Also check for any proto definitions that might define these fields fd -e proto | xargs rg 'payment_id|user_payment_id' || trueLength of output: 1844
Verify gRPC schema change for
payment_id→user_payment_idPlease confirm that the upstream gRPC transaction message has been updated to replace
payment_idwithuser_payment_idand that this field is populated in all responses. The Tauri adapter already mapstx.user_payment_idback to a JSONpayment_idfor the frontend, so no other code changes should be required—but you’ll need to ensure the gRPC definitions and server implementation align:
- Check your
.prototransaction message to verify it definesuser_payment_id(and no longer definespayment_id).- Ensure the gRPC server populates
user_payment_idon every transaction.- Since the adapter maps
tx.user_payment_id→payment_idin the JSON API, existing frontend code (e.g.transaction.payment_id) will continue to work.src-tauri/src/spend_wallet_adapter.rs (3)
108-138: Excellent refactoring for improved modularity and maintainability.Breaking down the transaction flow into discrete steps (
execute_recovery_command,execute_sync_command,execute_send_one_sided_command) makes the code more maintainable and testable. The export/import flow cleverly prevents direct broadcasting while allowing the view wallet to manage the transaction.
281-328: Comprehensive error reporting with Sentry integration.Excellent implementation of error reporting that captures all relevant context (exit code, stdout, stderr, command details) for debugging production issues. The combination of Sentry events and local logging provides both immediate visibility and long-term monitoring.
378-389: Good application of DRY principle with helper methods.Extracting base node information retrieval into dedicated methods eliminates code duplication and makes the code more maintainable.
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (2)
src/components/transactions/send/SendModal.tsx (2)
116-117: 🛠️ Refactor suggestionConsider moving hardcoded fee values to configuration.
The network fee and fee percentage are hardcoded, which could lead to maintenance issues and may not reflect actual network conditions.
Consider implementing a dynamic fee calculation system or at least moving these values to a configuration file or constants that can be easily updated. For example:
// In a constants file or configuration export const TRANSACTION_FEES = { NETWORK_FEE: 0.06, FEE_PERCENTAGE: 0.02 }; // Then use in the component networkFee={TRANSACTION_FEES.NETWORK_FEE} feePercentage={TRANSACTION_FEES.FEE_PERCENTAGE}
71-82: 🛠️ Refactor suggestionConsider refreshing transactions after successful send.
After a successful transaction (line 75), the transaction list should be refreshed to show the new pending transaction. Since
refreshTransactionswas imported but not used, this might have been the intended functionality.Add transaction refresh after successful send:
await invoke('send_one_sided_to_stealth_address', { ...payload, amount: payload.amount.toString(), }); setStatus('completed'); +await refreshTransactions();Note: If you implement this change, keep the
refreshTransactionsimport instead of removing it as suggested in the previous comment.
♻️ Duplicate comments (2)
src/utils/getTxStatus.ts (2)
17-35:⚠️ Potential issueFix counterintuitive status categorization.
The
txStates.pendingarray includesTransactionStatus.Completed, which is semantically incorrect. A completed transaction should not be categorized as pending.Apply this diff to fix the categorization:
const txStates = { pending: [ - TransactionStatus.Completed, TransactionStatus.Pending, TransactionStatus.Broadcast, TransactionStatus.Coinbase, TransactionStatus.Queued, + TransactionStatus.OneSidedUnconfirmed, ], failed: [TransactionStatus.Rejected, TransactionStatus.NotFound, TransactionStatus.CoinbaseNotInBlockChain], complete: [ + TransactionStatus.Completed, TransactionStatus.Imported, - TransactionStatus.OneSidedUnconfirmed, TransactionStatus.OneSidedConfirmed, TransactionStatus.MinedConfirmed, TransactionStatus.MinedUnconfirmed, TransactionStatus.CoinbaseConfirmed, TransactionStatus.CoinbaseUnconfirmed, ], };
47-53: 🛠️ Refactor suggestionImprove type safety and error handling.
The function has potential runtime issues due to dynamic object key access without proper type safety.
Apply this diff to improve type safety:
export function getTxStatusTitleKey(transaction: TransactionInfo): string | undefined { - return Object.keys(txStates).find((key) => { - if (txStates[key].includes(transaction.status)) { - return key; - } - }); + for (const [key, statuses] of Object.entries(txStates)) { + if (statuses.includes(transaction.status)) { + return key; + } + } + return undefined; }
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
src-tauri/src/commands.rs(2 hunks)src-tauri/src/wallet_adapter.rs(7 hunks)src-tauri/src/wallet_manager.rs(3 hunks)src/components/transactions/send/SendModal.tsx(1 hunks)src/utils/getTxStatus.ts(1 hunks)
🧰 Additional context used
🪛 GitHub Check: Run linters
src/components/transactions/send/SendModal.tsx
[warning] 10-10:
'refreshTransactions' is defined but never used. Allowed unused vars must match /^_/u
🪛 GitHub Actions: Lint
src/components/transactions/send/SendModal.tsx
[warning] 10-10: 'refreshTransactions' is defined but never used. Allowed unused vars must match /^_/u
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: tauri-build
- GitHub Check: cargo checks (fmt, clippy, check)
🔇 Additional comments (12)
src-tauri/src/commands.rs (3)
1891-1892: LGTM: Function signature update is well-motivated.The addition of the
app_handleparameter enables wallet balance update events to be emitted after transaction submission, which improves the user experience by keeping the UI synchronized.
1902-1902: LGTM: Function call updated correctly.The function call properly passes the new
view_wallet_managerparameter as indicated in the AI summary, maintaining consistency with the updated method signature.
1905-1909: LGTM: Balance update logic is well-implemented.The implementation properly retrieves the wallet balance and emits an update event only on success. The error handling is appropriate - if balance retrieval fails, it doesn't prevent the main transaction from succeeding, which is the correct behavior.
src-tauri/src/wallet_manager.rs (3)
30-30: LGTM: Import addition is necessary.The
WalletBalanceimport is required for the newget_balancemethod.
173-176: LGTM: get_balance method follows established patterns.The method correctly delegates to the adapter's
get_balancemethod while maintaining the same error handling pattern used throughout the codebase.
194-205: LGTM: import_transaction method with proper validation.The method includes appropriate validation by checking if the wallet is running before attempting the import operation. The error handling and delegation pattern is consistent with other methods in the class.
src/utils/getTxStatus.ts (2)
37-45: LGTM: Transaction type logic is well-structured.The function correctly categorizes transactions by type based on their status and direction, with appropriate fallback to 'unknown' for unhandled cases.
54-77: LGTM: Title generation logic with good prioritization.The function implements a clear hierarchy for title generation:
- Mined transactions show block height
- Transactions with meaningful payment messages show the message
- Fallback to type and status combination
The logic appropriately handles edge cases like excluding default messages and differentiating between complete and pending states.
src-tauri/src/wallet_adapter.rs (4)
101-111: LGTM! Clean implementation of balance retrieval.The
get_balancemethod properly handles connection errors and uses the newfrom_responsehelper for type conversion.
211-211: Good simplification of payment ID extraction.The change from
PaymentId::from_bytes(&tx.user_payment_id).user_data_as_string()toPaymentId::stringify_bytes(&tx.user_payment_id)simplifies the API usage while maintaining the same functionality.Also applies to: 279-279
323-326: Verify the reduced threshold is sufficient for reliable detection.The threshold for detecting if the wallet was scanned before the gRPC service started has been reduced from 10 to 5. While this improves responsiveness, ensure this is sufficient to avoid false positives on slower systems.
Consider monitoring this in production to ensure the reduced threshold doesn't cause premature returns on slower systems or during high load.
717-728: Well-structured helper methods for WalletBalance conversion.The addition of
from_responseandfrom_optionmethods provides a clean API for converting gRPC responses into the domain model, with proper handling of optional values.
3 participants
Summary by CodeRabbit
New Features
Improvements
Bug Fixes
Refactor
Style
Chores