Conversation
WalkthroughThis update simplifies transaction status display in the transaction info modal, adds Sentry monitoring to send modals for error tracking, and enhances blockchain explorer utilities to support both address and transaction links as well as explorer name retrieval. No changes were made to exported component signatures. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant TransactionInfo
participant BlockchainUtils
participant Explorer
User->>TransactionInfo: View transaction details
TransactionInfo->>BlockchainUtils: getBlockScanName(chainId)
TransactionInfo->>BlockchainUtils: getBlockScan(chainId, isAddress)
alt Status is Confirmed or Failed
TransactionInfo->>Explorer: Open explorer with tx hash or address
end
TransactionInfo-->>User: Display status, hash, and explorer link
sequenceDiagram
participant User
participant SendModal
participant Sentry
participant Blockchain
User->>SendModal: Initiate send
loop Polling for status
SendModal->>Blockchain: getUserOperationStatus
alt Status is Reverted or max attempts reached
SendModal->>Sentry: Capture warning/error with context
else Error occurs
SendModal->>Sentry: Capture exception with context
end
end
SendModal-->>User: Display send result
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 error Exit handler never called! 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
✨ 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
CodeRabbit Configuration File (
|
Deploying x with
|
| Latest commit: |
9cd8d09
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://cc0f96e3.x-e62.pages.dev |
| Branch Preview URL: | https://fix-history-userop-status-up.x-e62.pages.dev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
src/components/BottomMenuModal/SendModal/SendModalBatchesTabView.tsx (1)
244-268: Apply the same refactoring as suggested for SendModalTokensTabView.This file has the same code duplication issue as SendModalTokensTabView. Consider extracting the Sentry capturing logic into a shared utility function that both components can use.
Also applies to: 301-325
🧹 Nitpick comments (1)
src/components/BottomMenuModal/HistoryModal/TransactionInfo.tsx (1)
152-208: Consider simplifying the complex conditional logic.While the logic handles different scenarios appropriately, the nested conditionals are quite complex. Consider extracting the hash display logic into separate helper functions for better readability.
Also, please clarify why Polygon (chain ID 137) requires special handling in the display logic.
+const shouldShowCopyableHash = (status: string, hash: string, chainId: string) => { + return status === 'Confirmed' && hash && chainId !== '137'; +}; + +const shouldShowExplorerMessage = (status: string, hash: string, chainId: string) => { + return status !== 'Confirmed' || !hash || chainId === '137'; +}; // Then simplify the render logic: - {displayStatus !== 'Confirmed' && displayStatus !== 'Failed' ? ( - <div className="flex items-center justify-between max-w-full"> - <p className="text-xs text-light_purple font-normal truncate"> - Tx Hash:{' '} - <span className="font-normal text-white"> - {displayHash ?? '...'} - </span> - </p> - </div> - ) : ( - <CopyToClipboard - text={displayHash || ''} - onCopy={() => setCopied(true)} - > - <div className="flex items-center justify-between max-w-full cursor-pointer"> - {displayStatus !== 'Confirmed' || - !displayHash || - displayChainId === '137' ? ( - <div className="flex-1 min-w-0"> - <p className="text-xs white font-normal truncate"> - Please check the transaction status on{' '} - {getBlockScanName(Number(displayChainId))}: - </p> - </div> - ) : ( - // ... copyable hash JSX - )} - </div> - </CopyToClipboard> - )} + {renderTransactionHash()}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
src/apps/pillarx-app/components/TokenMarketDataRow/tests/__snapshots__/LeftColumnTokenMarketDataRow.test.tsx.snapis excluded by!**/*.snapsrc/apps/pillarx-app/components/TokensWithMarketDataTile/test/__snapshots__/TokensWithMarketDataTile.test.tsx.snapis excluded by!**/*.snap
📒 Files selected for processing (4)
src/components/BottomMenuModal/HistoryModal/TransactionInfo.tsx(6 hunks)src/components/BottomMenuModal/SendModal/SendModalBatchesTabView.tsx(6 hunks)src/components/BottomMenuModal/SendModal/SendModalTokensTabView.tsx(6 hunks)src/utils/blockchain.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: RanaBug
PR: pillarwallet/x#320
File: src/components/BottomMenuModal/HistoryModal/TransactionInfo.tsx:177-182
Timestamp: 2025-05-28T14:30:02.702Z
Learning: In the transaction history tracking feature, chain ID validation is performed earlier in the flow before the values reach the TransactionInfo component, so additional validation at the display level is not needed.
src/components/BottomMenuModal/SendModal/SendModalTokensTabView.tsx (1)
Learnt from: RanaBug
PR: pillarwallet/x#275
File: src/apps/the-exchange/components/DropdownTokensList/DropdownTokenList.tsx:180-195
Timestamp: 2025-03-28T09:22:22.712Z
Learning: In the Exchange app, `swapTokenList` and `receiveTokenList` are derived from `searchTokenResult` when search is active, so including `searchToken` in the useEffect dependency array that uses these lists would be redundant as the lists will update when search results change.
src/components/BottomMenuModal/HistoryModal/TransactionInfo.tsx (1)
Learnt from: RanaBug
PR: pillarwallet/x#320
File: src/components/BottomMenuModal/HistoryModal/TransactionInfo.tsx:177-182
Timestamp: 2025-05-28T14:30:02.702Z
Learning: In the transaction history tracking feature, chain ID validation is performed earlier in the flow before the values reach the TransactionInfo component, so additional validation at the display level is not needed.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: lint
- GitHub Check: unit-tests
- GitHub Check: build
🔇 Additional comments (13)
src/utils/blockchain.ts (2)
234-237: LGTM! Good addition of the default case.Adding a default case that returns an empty string provides better error handling for unsupported chain IDs.
239-258: LGTM! Well-implemented explorer name mapping.The new
getBlockScanNamefunction provides a clean way to retrieve explorer names for UI display purposes.src/components/BottomMenuModal/SendModal/SendModalTokensTabView.tsx (4)
17-17: LGTM! Good addition of Sentry for error monitoring.Adding Sentry integration will help with debugging and monitoring userOp status issues.
668-668: LGTM! Good use of a flag to prevent duplicate Sentry events.The
sentryCapturedflag ensures Sentry events are only sent once per polling cycle, preventing spam.
693-700: LGTM! Comprehensive Sentry payload structure.The payload includes all necessary context for debugging: wallet address, userOp hash, chain ID, transaction hash, attempts, and status.
806-819: LGTM! Good error handling with Sentry capture.The error handling for status fetch failures includes proper Sentry integration with relevant context.
src/components/BottomMenuModal/SendModal/SendModalBatchesTabView.tsx (3)
10-12: LGTM! Good addition of wallet address and Sentry integration.The additions are consistent with the error monitoring pattern established in other send modal components.
Also applies to: 69-69
204-204: LGTM! Consistent implementation of Sentry payload and flag.The implementation follows the same pattern as SendModalTokensTabView, which is good for consistency.
Also applies to: 225-232
335-346: LGTM! Consistent error handling pattern.The error handling for status fetch failures matches the pattern used in SendModalTokensTabView.
src/components/BottomMenuModal/HistoryModal/TransactionInfo.tsx (4)
2-2: LGTM! Good integration of wallet address and explorer utilities.The additions integrate well with the updated blockchain utilities and provide necessary context for the enhanced transaction display logic.
Also applies to: 15-15, 24-24
88-99: LGTM! Simplified and improved step logic.Reducing from 3 steps to 2 steps and grouping terminal states (
Sent,Confirmed,Failed) under the same step index makes the progress display cleaner and more intuitive.
101-113: LGTM! Clean status mapping function.The
stepsStatusfunction provides a clean abstraction for mapping detailed statuses to simplified display states.
230-251: LGTM! Great UX improvement for failed transactions.Adding a button that opens the explorer to the wallet address page for failed transactions is a thoughtful UX enhancement. Using
getBlockScanwith theisAddressparameter and showing the explorer name provides clear context to users.
| // Sentry capturing | ||
| if (!sentryCaptured) { | ||
| sentryCaptured = true; | ||
| // Polygon chain | ||
| if (chainIdForTxHash === 137) { | ||
| Sentry.captureMessage( | ||
| `Max attempts reached with userOp status "${status}" on Polygon`, | ||
| { | ||
| level: 'warning', | ||
| extra: sentryPayload, | ||
| } | ||
| ); | ||
| } else { | ||
| // Other chains | ||
| Sentry.captureException( | ||
| new Error( | ||
| `Max attempts reached with userOp status "${status}"` | ||
| ), | ||
| { | ||
| level: 'error', | ||
| extra: sentryPayload, | ||
| } | ||
| ); | ||
| } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Refactor duplicated Sentry capturing logic.
The same Sentry capturing logic is duplicated in two places. Consider extracting it into a helper function to follow DRY principles.
Also, please clarify why Polygon (chain ID 137) is treated differently with warning-level messages while other chains get error-level exceptions.
+const captureSentryUserOpError = (
+ chainId: number,
+ status: string,
+ sentryPayload: object,
+ sentryCaptured: boolean
+) => {
+ if (!sentryCaptured) {
+ if (chainId === 137) {
+ Sentry.captureMessage(
+ `Max attempts reached with userOp status "${status}" on Polygon`,
+ {
+ level: 'warning',
+ extra: sentryPayload,
+ }
+ );
+ } else {
+ Sentry.captureException(
+ new Error(`Max attempts reached with userOp status "${status}"`),
+ {
+ level: 'error',
+ extra: sentryPayload,
+ }
+ );
+ }
+ return true;
+ }
+ return sentryCaptured;
+};
// Then replace both occurrences with:
- // Sentry capturing
- if (!sentryCaptured) {
- sentryCaptured = true;
- // Polygon chain
- if (chainIdForTxHash === 137) {
- Sentry.captureMessage(
- `Max attempts reached with userOp status "${status}" on Polygon`,
- {
- level: 'warning',
- extra: sentryPayload,
- }
- );
- } else {
- // Other chains
- Sentry.captureException(
- new Error(
- `Max attempts reached with userOp status "${status}"`
- ),
- {
- level: 'error',
- extra: sentryPayload,
- }
- );
- }
- }
+ sentryCaptured = captureSentryUserOpError(
+ chainIdForTxHash,
+ status,
+ sentryPayload,
+ sentryCaptured
+ );Also applies to: 772-796
🤖 Prompt for AI Agents
In src/components/BottomMenuModal/SendModal/SendModalTokensTabView.tsx around
lines 714 to 738 and 772 to 796, the Sentry capturing logic is duplicated with
different handling for Polygon (chain ID 137) and other chains. Extract this
logic into a single helper function that accepts parameters like status,
chainIdForTxHash, and sentryPayload, and performs the appropriate Sentry capture
call based on the chain ID. Replace the duplicated code blocks with calls to
this helper function to adhere to DRY principles.
IAmKio
left a comment
IAmKio
left a comment
There was a problem hiding this comment.
Just a few suggestions and a question regarding err but other than that - looking good!
src/components/BottomMenuModal/SendModal/SendModalBatchesTabView.tsx
Outdated
Show resolved
Hide resolved
github-actions
bot
temporarily deployed
to
Preview (fix/history-userop-status-update)
github-actions
bot
temporarily deployed
to
Preview (fix/history-userop-status-update)
2 participants
Description
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Summary by CodeRabbit
New Features
Bug Fixes
Chores