RFQ-Indexer Adding events #3227
Conversation
WalkthroughThe pull request involves updates to documentation regarding the Synapse CCTP and RFQ contracts, clarifying their interactions with the Synapse CCTP Router and RFQ Router addresses. A new RFQ Indexer API documentation is introduced, enhancing access to indexed bridge event data. Additionally, modifications are made to configuration files and event handling logic within the RFQ indexer, including the addition of a new event listener for Changes
Possibly related PRs
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
|
Deploying sanguine-fe with
|
| Latest commit: |
560bae9
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://8db5f4ff.sanguine-fe.pages.dev |
| Branch Preview URL: | https://feat-rfq-indexer-updates.sanguine-fe.pages.dev |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3227 +/- ##
============================================
Coverage ? 90.56974%
============================================
Files ? 54
Lines ? 1018
Branches ? 82
============================================
Hits ? 922
Misses ? 93
Partials ? 3
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 increase total bundle size by 5.56MB (15.59%) ⬆️
ℹ️ *Bundle size includes cached data from a previous commit |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (12)
docs/bridge/docs/06-Services/06-RFQ-Indexer-API.md (1)
5-7: Consider improving the API documentation linkWhile the link is correctly formatted for Markdown, consider the following improvements:
- Use a relative link if the API documentation is part of the same repository.
- If it's an external link, ensure it uses HTTPS for security:
[API Documentation](https://triumphant-magic-production.up.railway.app/api-docs/)- Consider adding a brief description of what users can expect to find in the API documentation.
docs/bridge/docs/05-Contracts/05-CCTP.md (2)
9-9: Improved description of Synapse CCTP transactionsThe updated description provides a more accurate and detailed explanation of how Synapse CCTP transactions work. It clearly outlines the role of the Synapse CCTP Router contract and its interaction with the base Circle CCTP contracts.
Consider adding a brief explanation of what CCTP stands for (Cross-Chain Transfer Protocol) at the beginning of the paragraph for readers who might be unfamiliar with the acronym.
Line range hint
1-8: Consider adding a brief explanation of CCTPWhile the changes improve the document, it might be helpful to add a brief explanation of what CCTP (Cross-Chain Transfer Protocol) is at the beginning of the document. This would provide context for readers who might be unfamiliar with the term and improve the overall clarity of the documentation.
Consider adding a sentence like: "CCTP (Cross-Chain Transfer Protocol) is a protocol that enables the transfer of USDC across different blockchain networks."
docs/bridge/docs/05-Contracts/06-RFQ.md (1)
13-13: Improved description of RFQ transaction handlingThe updated description provides a clearer explanation of how RFQ transactions are processed, focusing on the role of the Router Address. This change aligns well with the PR objective of introducing new events to the indexer.
Consider adding a brief explanation of what RFQ stands for (Request for Quote) for readers who might be unfamiliar with the term.
packages/rfq-indexer/indexer/ponder.schema.ts (2)
84-94: LGTM: New BridgeProofDisputedEvents table addedThe addition of the
BridgeProofDisputedEventstable is well-structured and consistent with the existing schema. It includes all necessary fields for tracking proof dispute events, which aligns with the PR objective.Some observations:
- The field types are consistent with other tables in the schema.
- Common fields (id, transactionId, blockNumber, etc.) are present.
- New fields specific to proof disputes (relayer, chainId, chain) are appropriately included.
One minor suggestion for improvement:
Consider adding a comment above the table definition to briefly explain the purpose of
BridgeProofDisputedEvents. This would enhance code documentation and make it easier for other developers to understand the schema's structure.Example:
// Tracks events related to disputes over bridge proofs BridgeProofDisputedEvents: p.createTable({ // ... (existing fields) }),
Line range hint
41-94: Summary: Schema updates improve consistency and add new event trackingThe changes made to
ponder.schema.tssuccessfully achieve the PR objectives:
Linting improvements:
- Trailing commas added to
transactionHashfields in multiple tables.- Consistent formatting applied across the schema.
New event tracking:
BridgeProofDisputedEventstable added to track "bridgedispute" events.These updates enhance the schema's consistency and expand its capabilities for event tracking. The changes are well-structured and maintain the existing code style.
As the schema grows, consider grouping related tables (e.g., all bridge-related events) using comments or by organizing them into separate files if the schema becomes too large. This will improve maintainability and readability in the long term.
packages/rfq-indexer/indexer/src/index.ts (4)
55-81: LGTM: Improved event handler structure and consistencyThe refactoring of this event handler enhances code clarity and consistency with other handlers. The addition of
amountFormattedusing theformatAmountfunction ensures proper formatting of the amount.One minor suggestion:
Consider adding a comment explaining the purpose of the
trimfunction for readers unfamiliar with its use in blockchain addresses.
85-116: LGTM: Improved event handler structure and data managementThe refactoring enhances code clarity and consistency. The use of
upsertis a good practice, allowing for updating existing records.Suggestions:
- Consider removing or updating the comment on line 89 about the 'address' field if it's not currently used.
- Add a brief comment explaining the rationale behind using
upsertinstead ofcreatefor this specific event.
150-175: LGTM: Well-structured new event handler for BridgeProofDisputedThe new event handler for 'FastBridgeV2:BridgeProofDisputed' is well-structured and consistent with other handlers. It captures all necessary fields and follows established patterns.
Suggestion:
Consider adding a brief comment explaining the purpose of this new event handler and how it fits into the overall bridge dispute resolution process. This would improve code documentation and help future developers understand the context.
Line range hint
1-222: Overall Assessment: Excellent improvements to event handling and code structureThis PR successfully achieves its objectives of cleaning up linting errors and introducing the "bridgedispute" event. The changes consistently enhance code clarity, readability, and functionality across all event handlers. Key improvements include:
- Consistent formatting of amount fields using
formatAmount.- Refactoring of event handlers for improved readability and consistency.
- Addition of the new 'FastBridgeV2:BridgeProofDisputed' event handler.
- Consistent use of the
trimfunction for address fields.These changes will significantly improve the maintainability and reliability of the RFQ-Indexer component.
To further enhance the codebase:
- Consider extracting common event handling logic into shared utility functions to reduce code duplication.
- Implement comprehensive error handling and logging for each event handler to improve system robustness.
- Document the overall architecture and flow of events in a separate markdown file to aid future developers in understanding the system.
packages/rfq-indexer/indexer/ponder.config.ts (2)
18-72: LGTM! Consider using constants for block numbers.The updates to
FastBridgeV2StartBlockvalues and the addition of the BNB network are good improvements. Retaining comments about the first block provides useful historical context.Consider defining constants for the block numbers at the top of the file. This would make it easier to update them in the future and provide a clear overview of all start blocks. For example:
const ETHEREUM_START_BLOCK = 20426589; const OPTIMISM_START_BLOCK = 123416470; // ... other constants ... const configByChainId = { [1]: { // ... FastBridgeV2StartBlock: ETHEREUM_START_BLOCK, }, // ... other networks ... }
143-226: LGTM! Consider addressing the commented outdisableCacheoptions.The reformatting of the
networksandcontractssections improves readability and maintainability. The use ofnetworkDetailsin thecontractssection is a good practice that reduces duplication and potential inconsistencies. The addition of the BNB network is consistent with the earlier changes.The commented out
disableCacheoptions in thenetworkssection should be addressed. If they're no longer needed, consider removing them. If they're intended for future use, add a TODO comment explaining when or under what conditions they should be uncommented.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (10)
- docs/bridge/docs/05-Contracts/05-CCTP.md (1 hunks)
- docs/bridge/docs/05-Contracts/06-RFQ.md (1 hunks)
- docs/bridge/docs/06-Services/06-RFQ-Indexer-API.md (1 hunks)
- packages/rfq-indexer/api/README.md (1 hunks)
- packages/rfq-indexer/indexer/ponder.config.ts (1 hunks)
- packages/rfq-indexer/indexer/ponder.schema.ts (3 hunks)
- packages/rfq-indexer/indexer/src/index.ts (3 hunks)
- packages/rfq-indexer/indexer/src/types.ts (1 hunks)
- packages/rfq-indexer/indexer/src/utils/chains.ts (1 hunks)
- packages/rfq-indexer/indexer/src/utils/generateEntryId.ts (1 hunks)
✅ Files skipped from review due to trivial changes (3)
- packages/rfq-indexer/indexer/src/types.ts
- packages/rfq-indexer/indexer/src/utils/chains.ts
- packages/rfq-indexer/indexer/src/utils/generateEntryId.ts
🧰 Additional context used
🪛 Markdownlint
packages/rfq-indexer/api/README.md
5-5: null
Bare URL used(MD034, no-bare-urls)
🔇 Additional comments (12)
docs/bridge/docs/06-Services/06-RFQ-Indexer-API.md (2)
1-3: LGTM: Clear and informative introductionThe title and introduction effectively communicate the purpose and benefits of the RFQ Indexer API. The content is well-written and provides a good overview for users.
1-14: Overall, good introduction to the RFQ Indexer API with room for minor improvementsThis document provides a clear and concise introduction to the RFQ Indexer API. The suggested improvements, such as fixing the numbering in the Key Features section and expanding on the feature descriptions, will enhance the document's clarity and usefulness. Additionally, ensuring the API documentation link is secure and possibly relative will improve the overall quality and maintainability of the documentation.
These changes will make the document more informative and user-friendly, providing a better understanding of the RFQ Indexer API's capabilities and benefits to potential users.
docs/bridge/docs/05-Contracts/05-CCTP.md (1)
11-11: Improved clarity in address labelThe change from "Address" to "Synapse CCTP Router Address" provides more specific and accurate information about the contract associated with the given address. This improvement enhances the overall clarity of the documentation.
docs/bridge/docs/05-Contracts/06-RFQ.md (2)
Line range hint
5-9: Good addition of a disclaimer noteThe added note improves transparency by acknowledging that the list may be incomplete and directing readers to the canonical source. This is a good practice in documentation.
17-17: Improved clarity in address labelingThe change from "Address" to "RFQ Router Address" provides more specific context for the listed address. This improvement aligns well with the updated description and enhances the overall clarity of the documentation.
packages/rfq-indexer/indexer/ponder.schema.ts (3)
41-41: LGTM: Trailing comma added for consistencyThe addition of a trailing comma to the
transactionHashfield in theBridgeRelayedEventstable is a good practice. It improves code consistency and makes future additions to the table easier.
66-66: LGTM: Consistent trailing comma additionThe addition of a trailing comma to the
transactionHashfield in theBridgeDepositRefundedEventstable is consistent with the previous change. This maintains a uniform style throughout the schema.
81-82: LGTM: Improved formatting for better readabilityThe changes to the
BridgeDepositClaimedEventstable are good:
- The addition of a trailing comma to the
transactionHashfield maintains consistency with other tables.- Moving the closing parenthesis to a new line improves readability and makes future additions easier.
These changes contribute to a more maintainable and consistent codebase.
packages/rfq-indexer/indexer/src/index.ts (3)
43-44: LGTM: Improved consistency in amount formattingThe addition of
originAmountFormattedusing theformatAmountfunction enhances consistency with other event handlers and ensures proper formatting of the amount.
120-147: LGTM: Consistent improvements in event handler structureThe refactoring of this event handler maintains the improved code clarity and consistency seen in other handlers. The addition of
amountFormattedand the use of thetrimfunction for address fields are good practices that have been consistently applied.
180-222: LGTM: Comprehensive improvements in BridgeRelayed event handlerThe refactoring of the 'FastBridgeV2:BridgeRelayed' event handler significantly enhances code clarity and consistency. The addition of
originAmountFormattedanddestAmountFormattedfields ensures proper formatting for both origin and destination amounts, which is crucial for accurate data representation. The consistent use of thetrimfunction for address fields maintains good practices across all handlers.packages/rfq-indexer/indexer/ponder.config.ts (1)
76-139: LGTM! Good refactoring for consistency.The refactoring of the
networkDetailsobject to use theconfigByChainIdobject improves consistency and reduces the chance of errors when updating configurations. The addition of the BNB network is also consistent with the changes in theconfigByChainIdobject.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (9)
docs/bridge/docs/06-Services/06-RFQ-Indexer-API.md (1)
5-7: Consider using a more generic URL for API documentationWhile the provided link is functional, using a production URL (https://triumphant-magic-production.up.railway.app/api-docs/) in the documentation might lead to maintenance issues in the future. Consider using a more generic or configurable URL that can be easily updated across environments.
For example, you could use a relative path or a placeholder that can be replaced during deployment:
[API Documentation](/api-docs/)or
[API Documentation]({{API_DOCS_URL}})This approach would make it easier to maintain the documentation across different environments and deployments.
docs/bridge/docs/05-Contracts/05-CCTP.md (2)
9-9: Improved description of Synapse CCTP transactionsThe updated description provides a clearer and more accurate explanation of how Synapse CCTP transactions work. It effectively clarifies the role of the Synapse CCTP Router contract and its interaction with the base Circle CCTP contracts.
Consider adding a brief explanation of what "CCTP" stands for, as it's not explicitly defined in this section. This would improve clarity for readers who might be unfamiliar with the acronym.
Line range hint
1-5: Consider revising the note about incomplete listThe note at the beginning of the document stating "This list may be incomplete" seems out of place in the context of the CCTP documentation. It's not clear if this note applies specifically to the CCTP information or to a broader set of contracts.
Consider either removing this note if it's not directly relevant to the CCTP documentation, or clarifying its scope to avoid potential confusion for readers.
docs/bridge/docs/05-Contracts/06-RFQ.md (1)
17-17: Improved labeling of the Router AddressThe change from "Address" to "RFQ Router Address" provides better context and aligns with the updated description. This improvement enhances the clarity of the documentation.
For consistency with the earlier description, consider changing "RFQ Router Address" to "Router Address". This would maintain a uniform terminology throughout the document.
-**RFQ Router Address**: `0x00cD000000003f7F682BE4813200893d4e690000` +**Router Address**: `0x00cD000000003f7F682BE4813200893d4e690000`packages/rfq-indexer/indexer/ponder.schema.ts (1)
84-94: LGTM: New BridgeProofDisputedEvents table addedThe addition of the
BridgeProofDisputedEventstable aligns with the PR objective of introducing the "bridgedispute" event to the indexer. The table structure and field types are consistent with other tables in the schema.Consider renaming
chainIdtooriginChainIdandchaintooriginChainfor consistency with other tables in the schema. This would make it easier to query and join tables in the future if needed.BridgeProofDisputedEvents: p.createTable({ id: p.string(), transactionId: p.string(), relayer: p.string(), - chainId: p.int(), - chain: p.string(), + originChainId: p.int(), + originChain: p.string(), blockNumber: p.bigint(), blockTimestamp: p.int(), transactionHash: p.string(), }),packages/rfq-indexer/indexer/src/index.ts (3)
Line range hint
9-52: LGTM! Improved code structure and consistency.The restructuring of the 'BridgeRequested' event handler enhances readability and maintainability. The consistent use of
formatAmountfororiginAmountFormattedis a good practice.Consider applying the same formatting consistency to
destAmountFormatted:- destAmountFormatted: formatAmount(destAmount, destToken), + destAmountFormatted: formatAmount(destAmount, destToken),This ensures uniform formatting across all amount fields.
85-116: LGTM! Improved code structure and added helpful comment.The restructuring of the 'BridgeProofProvided' event handler enhances readability and maintainability. The comment about potentially adding the 'address' field in the future is a good reminder for future enhancements.
Regarding the comment on line 89:
log: { address, blockNumber }, // may want to add address here eventuallyWould you like me to create a GitHub issue to track the potential addition of the 'address' field in the future? This can help ensure this enhancement isn't forgotten.
150-175: LGTM! Well-structured new event handler.The new 'BridgeProofDisputed' event handler is a great addition that aligns with the PR objectives. It follows the consistent structure and style of other handlers in the file.
For consistency with other handlers, consider renaming
chainIdandchaintooriginChainIdandoriginChain:- chainId: Number(chainId), - chain: getChainName(Number(chainId)), + originChainId: Number(chainId), + originChain: getChainName(Number(chainId)),This change would make the field names consistent across all event handlers.
packages/rfq-indexer/indexer/ponder.config.ts (1)
18-72: LGTM! Consider adding comments for new networks.The updates to
FastBridgeV2StartBlockvalues across multiple networks are consistent and well-documented. The addition of Linea and BNB networks expands the configuration's coverage.Consider adding comments for the new Linea and BNB networks, similar to the other networks, to maintain consistency:
[59144]: { transport: http(process.env.LINEA_MAINNET_RPC), chainName: 'linea', FastBridgeV2Address: '0x34F52752975222d5994C206cE08C1d5B329f24dD', - FastBridgeV2StartBlock: 7124666, // first block and new block + FastBridgeV2StartBlock: 7124666, // first block }, [56]: { transport: http(process.env.BNB_MAINNET_RPC), chainName: 'bnb', FastBridgeV2Address: '0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E', - FastBridgeV2StartBlock: 40497843, // first block and new block + FastBridgeV2StartBlock: 40497843, // first block },
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (10)
- docs/bridge/docs/05-Contracts/05-CCTP.md (1 hunks)
- docs/bridge/docs/05-Contracts/06-RFQ.md (1 hunks)
- docs/bridge/docs/06-Services/06-RFQ-Indexer-API.md (1 hunks)
- packages/rfq-indexer/api/README.md (1 hunks)
- packages/rfq-indexer/indexer/ponder.config.ts (1 hunks)
- packages/rfq-indexer/indexer/ponder.schema.ts (3 hunks)
- packages/rfq-indexer/indexer/src/index.ts (3 hunks)
- packages/rfq-indexer/indexer/src/types.ts (1 hunks)
- packages/rfq-indexer/indexer/src/utils/chains.ts (1 hunks)
- packages/rfq-indexer/indexer/src/utils/generateEntryId.ts (1 hunks)
✅ Files skipped from review due to trivial changes (3)
- packages/rfq-indexer/indexer/src/types.ts
- packages/rfq-indexer/indexer/src/utils/chains.ts
- packages/rfq-indexer/indexer/src/utils/generateEntryId.ts
🧰 Additional context used
🪛 Markdownlint
packages/rfq-indexer/api/README.md
5-5: null
Bare URL used(MD034, no-bare-urls)
🔇 Additional comments (11)
docs/bridge/docs/06-Services/06-RFQ-Indexer-API.md (1)
1-3: LGTM: Clear and informative introductionThe title and introduction provide a concise and clear overview of the RFQ Indexer API, its purpose, and its benefits. The content is well-written and effectively communicates the API's role in monitoring and operational capabilities.
docs/bridge/docs/05-Contracts/05-CCTP.md (1)
11-11: Improved clarity in address labelThe change from "Address" to "Synapse CCTP Router Address" provides better context and aligns well with the updated description. This improvement enhances the overall clarity of the documentation.
docs/bridge/docs/05-Contracts/06-RFQ.md (1)
13-14: Improved clarity on RFQ transaction flowThe updated description provides a more accurate explanation of how RFQ transactions are processed. It correctly emphasizes the role of the Router Address in routing transactions to the appropriate RFQ contract on the relevant chain. This change enhances the documentation's accuracy and aligns with the PR's objective of improving the RFQ-Indexer component.
packages/rfq-indexer/indexer/ponder.schema.ts (2)
41-41: LGTM: Trailing comma added for consistencyAdding a trailing comma to the
transactionHashfield improves code consistency and makes future additions to the table schema easier.
66-66: LGTM: Consistent trailing comma additionsThe addition of trailing commas to the
transactionHashfields inBridgeDepositRefundedEventsandBridgeDepositClaimedEventstables maintains consistency with other table definitions. This improves overall code readability and maintainability.Also applies to: 81-82
packages/rfq-indexer/indexer/src/index.ts (4)
55-81: LGTM! Improved code structure and consistency.The restructuring of the 'BridgeDepositRefunded' event handler enhances readability and aligns with the style used in other handlers. This promotes consistency across the file without altering the underlying functionality.
120-147: LGTM! Consistent improvement in code structure.The restructuring of the 'BridgeDepositClaimed' event handler enhances readability and aligns with the style used in other handlers. This promotes consistency across the file without altering the underlying functionality.
180-222: LGTM! Consistent improvement in code structure.The restructuring of the 'BridgeRelayed' event handler enhances readability and aligns with the style used in other handlers. This promotes consistency across the file without altering the underlying functionality.
Line range hint
1-222: Overall, excellent improvements to code structure and functionality.This PR successfully achieves its objectives:
- It improves code readability and consistency across all event handlers.
- It adds the new 'BridgeProofDisputed' event handler, enhancing the indexer's functionality.
These changes will make the code easier to maintain and extend in the future. Great job on improving the overall quality of the RFQ-Indexer component!
packages/rfq-indexer/indexer/ponder.config.ts (2)
76-139: LGTM! Consistent network details structure.The
networkDetailsobject has been updated consistently with theconfigByChainIdobject. The structure is uniform across all network configurations, including the newly added Linea and BNB networks. This consistency enhances maintainability and readability of the configuration.
143-226: LGTM! Consider clarifying thedisableCachecomments.The
createConfigfunction has been updated consistently with theconfigByChainIdandnetworkDetailsobjects. The structure is uniform across all network configurations, including the newly added Linea and BNB networks.The commented-out
disableCacheoptions are present for each network. It's unclear whether these are intended for future use or should be removed. Please clarify the intention behind these comments.To verify the usage of
disableCachein the codebase, you can run the following script:This will help determine if
disableCacheis used elsewhere in the project and provide context for its intended use.✅ Verification successful
Clarification on
disableCacheImplementationsThe
disableCacheoption is enabled globally inponder.config.ts(disableCache: true) and remains commented out in each network's configuration. This setup indicates that caching is disabled by default across all networks, with the ability to enable it individually by uncommenting the relevant lines. Consider updating the comments to clarify this configuration for better code maintainability.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for other occurrences of disableCache in the codebase # Search for disableCache in TypeScript files echo "Searching for disableCache in TypeScript files:" rg --type typescript 'disableCache' -C 2 # Search for disableCache in JavaScript files echo "Searching for disableCache in JavaScript files:" rg --type javascript 'disableCache' -C 2Length of output: 361
Script:
#!/bin/bash # Description: Check for other occurrences of disableCache in the codebase # Search for disableCache in TypeScript files echo "Searching for disableCache in TypeScript files:" rg 'disableCache' --glob '*.ts' -C 2 # Search for disableCache in JavaScript files echo "Searching for disableCache in JavaScript files:" rg 'disableCache' --glob '*.js' -C 2Length of output: 4011
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
packages/rfq-indexer/indexer/src/index.ts (1)
84-116: LGTM: Improved readability and appropriate use of upsertThe 'FastBridgeV2:BridgeProofProvided' event listener has been reformatted for better readability. The use of an upsert operation is appropriate for handling potential duplicate events.
Consider reviewing the comment about the 'address' field
There's a comment on line 89 about potentially adding the 'address' field in the future. It might be worth discussing if this addition is necessary and, if so, planning its implementation.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
- packages/rfq-indexer/indexer/src/index.ts (3 hunks)
🔇 Additional comments (6)
packages/rfq-indexer/indexer/src/index.ts (6)
Line range hint
9-52: LGTM: Improved formatting and consistencyThe changes to the 'FastBridgeV2:BridgeRequested' event listener enhance readability and maintain consistency. The use of the
formatAmountutility fororiginAmountFormattedis a good practice.
54-81: LGTM: Enhanced readabilityThe 'FastBridgeV2:BridgeDepositRefunded' event listener has been reformatted for improved readability while maintaining the original functionality.
119-147: LGTM: Improved readabilityThe 'FastBridgeV2:BridgeDepositClaimed' event listener has been reformatted for better readability while maintaining the original functionality.
150-181: LGTM: New event listener added with appropriate upsert operationThe new 'FastBridgeV2:BridgeProofDisputed' event listener has been implemented correctly, following the structure of other listeners in the file. The use of an upsert operation is appropriate for handling potential multiple disputes, as suggested in a previous review comment.
185-228: LGTM: Enhanced readabilityThe 'FastBridgeV2:BridgeRelayed' event listener has been reformatted for improved readability while maintaining the original functionality.
Line range hint
1-228: Overall LGTM: Improved code structure and new event handlingThe changes in this file have significantly improved the code structure and readability across all event listeners. The addition of the 'FastBridgeV2:BridgeProofDisputed' event listener enhances the functionality of the indexer. All modifications align well with the existing code patterns and best practices.
Suggestions for future improvements:
- Consider implementing the 'address' field addition mentioned in the 'BridgeProofProvided' event listener if it's deemed necessary.
- Ensure that all new events are properly tested, especially the newly added 'BridgeProofDisputed' event.
Great job on improving the code quality and expanding the indexer's capabilities!
Defi-Moses
requested review from
ChiTimesChi,
bigboydiamonds,
abtestingalpha and
aureliusbtc
as code owners
This PR does two things:
c348391: docs preview link
Summary by CodeRabbit
New Features
BridgeProofDisputedevents.Documentation
Bug Fixes
Chores
0c9d3f8: docs preview link