feat: add sepolia requests to Request Scan #79
Conversation
WalkthroughThe changes in this pull request involve multiple updates across several files to incorporate support for the Changes
Assessment against linked issues
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
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
CodeRabbit Configuration File (
|
![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 (5)
src/lib/types.ts (2)
36-36: LGTM! Consider adding JSDoc comment.The optional network property with literal types is well-implemented. Consider adding a JSDoc comment to document the purpose of this property and when it might be undefined.
+ /** The network where the transaction was processed. Undefined for legacy transactions. */ network?: "gnosis" | "sepolia";
43-43: LGTM! Consider adding JSDoc comment.The optional source property with literal types is well-implemented. Consider adding a JSDoc comment to document the purpose of this property and when it might be undefined.
+ /** The storage source of the channel. Undefined for legacy channels. */ source?: "storage" | "storage_sepolia";src/app/request/[id]/page.tsx (2)
46-51: Consider improving gateway URL management and type safetyThe
getGatewayfunction could benefit from the following improvements:
- Move gateway URLs to environment variables or constants for better maintainability
- Add proper type safety for the source property
- Implement null safety in the conditional check
Consider this implementation:
+const GATEWAY_URLS = { + SEPOLIA: "sepolia.gateway.request.network", + GNOSIS: "gnosis.gateway.request.network" +} as const; -const getGateway = (request: Channel | null) => { +const getGateway = (request: Channel | null): string => { + if (!request?.source) return GATEWAY_URLS.GNOSIS; + return request.source === "storage_sepolia" + ? GATEWAY_URLS.SEPOLIA + : GATEWAY_URLS.GNOSIS; };
Line range hint
124-141: Improve code clarity and robustness in payment reference calculationThe payment reference calculation logic could be more robust and readable:
- Consider extracting the deeply nested property access into a helper function
- Add type guards to handle potential undefined values more explicitly
Consider this approach:
const getPaymentReferenceParams = (request: Channel) => { const firstTransaction = request?.transactions[0]; const extensionsData = firstTransaction?.dataObject?.data?.parameters?.extensionsData?.[0]?.parameters; return { salt: extensionsData?.salt ?? "", paymentAddress: extensionsData?.paymentAddress ?? "" }; }; const shortPaymentReference = request ? calculateShortPaymentReference( id, ...Object.values(getPaymentReferenceParams(request)) ) : "";src/lib/queries/channel.ts (1)
74-80: Useunknowntype for caught errors and properly narrow the typeIn TypeScript, it's recommended to type caught errors as
unknownand then narrow them to ensure type safety.Apply the following changes:
// Inside the transactions map function } catch (error: any) { + } catch (error: unknown) { + if (error instanceof Error) { console.error(`Error parsing transaction data: ${error.message}`); + } else { + console.error(`Error parsing transaction data`); + } return transaction; }Apply this change to both
catchblocks to enhance type safety.Also applies to: 94-100
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
src/app/request/[id]/page.tsx(13 hunks)src/lib/queries/address-transactions.ts(3 hunks)src/lib/queries/channel.ts(2 hunks)src/lib/queries/transactions.ts(3 hunks)src/lib/types.ts(1 hunks)
🔇 Additional comments (6)
src/app/request/[id]/page.tsx (2)
251-254: LGTM! Gateway integration is well implemented
The gateway information is correctly integrated into the request details table, following the existing structure and patterns.
Line range hint 1-377: Verify network handling across the codebase
Let's ensure the codebase consistently handles both networks (Sepolia and Gnosis).
✅ Verification successful
Network handling implementation is consistent and well-structured
The codebase demonstrates proper handling of both Sepolia and Gnosis networks through:
- Clear type definitions for network sources (
storageandstorage_sepolia) - Consistent GraphQL queries that fetch data from both networks
- Proper network-specific gateway URL resolution
- Comprehensive transaction handling across both networks with proper sorting and merging
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent network handling across the codebase
# Check for network-related constants and configurations
echo "Checking network configurations..."
rg -l "storage_sepolia|gnosis\.gateway|sepolia\.gateway" --type ts --type tsx
# Check for potential hardcoded gateway URLs
echo "Checking for hardcoded gateway URLs..."
rg "gateway\.request\.network" --type ts --type tsx
# Look for network-specific error handling
echo "Checking network-specific error handling..."
rg "network.*error|error.*network" --type ts --type tsx
Length of output: 538
Script:
#!/bin/bash
# Description: Check for consistent network handling across the codebase (corrected file types)
# Check for network-related constants and configurations
echo "Checking network configurations..."
rg -l "storage_sepolia|gnosis\.gateway|sepolia\.gateway"
# Check for potential hardcoded gateway URLs
echo "Checking for hardcoded gateway URLs..."
rg "gateway\.request\.network"
# Look for network-specific error handling
echo "Checking network-specific error handling..."
rg "network.*error|error.*network"
Length of output: 686
Script:
#!/bin/bash
# Let's examine the network handling implementation in the identified files
echo "Checking network handling in types.ts..."
cat src/lib/types.ts
echo -e "\nChecking network handling in queries..."
cat src/lib/queries/channel.ts
cat src/lib/queries/transactions.ts
cat src/lib/queries/address-transactions.ts
Length of output: 8001
src/lib/queries/address-transactions.ts (3)
7-7: Good use of getAddress from viem library
Importing getAddress from viem ensures that Ethereum addresses are checksummed correctly, which enhances the reliability of address handling in your application.
81-84: Ensure TypeScript types accommodate new data structure
Updating the data type to include storage_sepolia is necessary for handling Sepolia transactions. Ensure that the Transaction interface correctly represents any differences between transactions from storage and storage_sepolia, and update type definitions if needed.
40-63: Verify inclusion of storage_sepolia in GraphQL schema
Adding the storage_sepolia section to the ADDRESS_TRANSACTIONS_QUERY allows fetching transactions from the Sepolia network. However, to ensure correctness, verify that the GraphQL endpoint supports the storage_sepolia field and that it returns the expected data.
Run the following script to confirm that storage_sepolia is a valid field in the GraphQL schema:
Replace <GraphQL_endpoint_URL> with the actual endpoint URL.
This script retrieves the schema and checks if storage_sepolia is among the queryable fields.
✅ Verification successful
Let's first understand if and where storage_sepolia is defined or configured in the codebase before making assumptions about the schema.
Let's analyze how storage_sepolia is used across the codebase to verify its implementation and consistency.
storage_sepolia is correctly implemented and used consistently across the codebase
The verification shows that storage_sepolia is:
- Properly typed in
types.tsas a valid source option - Used consistently in multiple GraphQL queries (
transactions.ts,channel.ts,address-transactions.ts) - Handled appropriately in data processing with proper null checks and transformations
- Integrated into the application logic for determining gateway URLs
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that 'storage_sepolia' is a valid field in the GraphQL schema.
# Fetch the GraphQL schema and search for 'storage_sepolia'
curl -X POST -H "Content-Type: application/json" \
--data '{"query": "query { __schema { types { name fields { name } } } }"}' \
<GraphQL_endpoint_URL> | jq '.data.__schema.types[] | select(.name=="Query") | .fields[] | .name' | grep 'storage_sepolia'
Length of output: 310
Script:
#!/bin/bash
# Let's search for GraphQL schema definitions and configurations in the codebase
# that might reference 'storage_sepolia'
# Search for files containing 'storage_sepolia'
rg -l "storage_sepolia"
# Search for GraphQL schema files
fd "\.(graphql|gql)$"
# Look for any configuration files that might contain GraphQL endpoint or schema info
fd "(config|schema)\.(ts|js|json)$"
Length of output: 264
Script:
#!/bin/bash
# Let's examine the usage of storage_sepolia in the related files to understand its implementation
# Check types.ts for type definitions
rg -A 10 "storage_sepolia" src/lib/types.ts
# Check other query files to see how storage_sepolia is used
rg -A 10 "storage_sepolia" src/lib/queries/transactions.ts
rg -A 10 "storage_sepolia" src/lib/queries/channel.ts
# Check the page component to see how it's used in the application
rg -A 10 "storage_sepolia" src/app/request/[id]/page.tsx
Length of output: 2661
src/lib/queries/channel.ts (1)
32-54: LGTM: Addition of storage_sepolia to the GraphQL query
The storage_sepolia section has been correctly added to the query, mirroring the existing storage structure.
aimensahnoun
deleted the
78-add-requests-created-on-sepolia-gateway-to-request-scan
branch
Resolves #78
CleanShot.2024-11-28.at.03.16.41.mp4
Summary by CodeRabbit
Release Notes
New Features
storage_sepolia.Improvements
storageandstorage_sepolia.Bug Fixes
These changes improve the overall functionality and flexibility of the application, allowing for better handling of transactions across multiple networks.