merging rfq indexer into monorepo [SLT-164] [SLT-176] #3136
Conversation
Defi-Moses
requested review from
bigboydiamonds,
abtestingalpha and
trajan0x
as code owners
WalkthroughThe changes introduce modifications to the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Recent review detailsConfiguration used: .coderabbit.yaml Files selected for processing (1)
Files skipped from review as they are similar to previous 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
Documentation and Community
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3136 +/- ##
===================================================
+ Coverage 36.37752% 37.94554% +1.56802%
===================================================
Files 438 418 -20
Lines 25535 24240 -1295
Branches 82 82
===================================================
- Hits 9289 9198 -91
+ Misses 15505 14303 -1202
+ Partials 741 739 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Deploying sanguine-fe with
|
| Latest commit: |
635d8e2
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://71be20e5.sanguine-fe.pages.dev |
| Branch Preview URL: | https://add-rfq-indexer.sanguine-fe.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
Outside diff range and nitpick comments (4)
packages/rfq-indexer/indexer/src/utils/generateEntryId.ts (1)
2-2: Remove the redundantNumber()call.Since
dbNonceis already declared as anumbertype, wrapping it withNumber()is unnecessary.Apply this diff to remove the redundant call:
-return `${chainId}-${Number(dbNonce)}` +return `${chainId}-${dbNonce}`packages/rfq-indexer/indexer/ponder.schema.ts (1)
4-22: The table structure and field names look good, but consider makingoriginAmountrequired.The
BridgeRequestEventstable captures essential details about bridge requests with descriptive field names and appropriate types. However, theoriginAmountfield is marked as optional, which could lead to inconsistencies. Consider making it required unless there's a valid reason for it to be optional.packages/rfq-indexer/api/src/constants/networkConfig.ts (1)
1-108: Suggestions for improving the network configurationThe code in
networkConfig.tsprovides a structured configuration for interacting with theFastBridgeV2contract across different blockchain networks. The overall structure and functionality of the code are well-implemented and consistent.Here are a few suggestions for potential improvements:
Consider moving the hardcoded contract addresses to a separate configuration file. This would make it easier to maintain and update the addresses if needed, without modifying the code itself.
The repeated structure of each network entry could be simplified using a loop or a helper function. You could define an array of supported networks with their respective details (name, chain ID, contract address) and generate the
networkConfigobject dynamically based on that array. This would reduce code duplication and make it easier to add or remove networks in the future.Adding comments to explain the purpose and structure of the configuration would enhance the code's readability and maintainability. Consider adding a brief description of what the
networkConfigobject represents and how it is used within the project.Overall, the code is well-structured and provides a solid foundation for interacting with the
FastBridgeV2contract across multiple networks. The suggestions mentioned above are minor improvements that could further enhance the code's maintainability and scalability.packages/rfq-indexer/indexer/ponder.config.ts (1)
142-224: LGTM, but consider enabling caching only in production.The
configobject is correctly constructed using thecreateConfigfunction and includes the necessary network details and contract specifications.However, consider enabling caching only in the production environment to avoid potential issues during development and testing.
To enable caching only in production, you can modify the code as follows:
- // disableCache: configByChainId.disableCache, + disableCache: process.env.NODE_ENV !== 'production',
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files ignored due to path filters (3)
packages/rfq-indexer/api/pnpm-lock.yamlis excluded by!**/pnpm-lock.yamlpackages/rfq-indexer/api/yarn.lockis excluded by!**/yarn.lock,!**/*.lockpackages/rfq-indexer/yarn.lockis excluded by!**/yarn.lock,!**/*.lock
Files selected for processing (33)
- packages/rfq-indexer/.dockerignore (1 hunks)
- packages/rfq-indexer/.nvmrc (1 hunks)
- packages/rfq-indexer/api/.env (1 hunks)
- packages/rfq-indexer/api/.gitignore (1 hunks)
- packages/rfq-indexer/api/nixpacks.toml (1 hunks)
- packages/rfq-indexer/api/package.json (1 hunks)
- packages/rfq-indexer/api/src/constants/abis/FastBridgeV2.ts (1 hunks)
- packages/rfq-indexer/api/src/constants/networkConfig.ts (1 hunks)
- packages/rfq-indexer/api/src/db/index.ts (1 hunks)
- packages/rfq-indexer/api/src/graphql/queries/queries.graphql (1 hunks)
- packages/rfq-indexer/api/src/graphql/resolvers.ts (1 hunks)
- packages/rfq-indexer/api/src/graphql/schema.ts (1 hunks)
- packages/rfq-indexer/api/src/graphql/types/events.graphql (1 hunks)
- packages/rfq-indexer/api/src/index.ts (1 hunks)
- packages/rfq-indexer/api/src/tsconfig.json (1 hunks)
- packages/rfq-indexer/api/src/types/index.ts (1 hunks)
- packages/rfq-indexer/api/src/utils/overrideJsonBigIntSerialization.ts (1 hunks)
- packages/rfq-indexer/indexer/.env.example (1 hunks)
- packages/rfq-indexer/indexer/.eslintrc.json (1 hunks)
- packages/rfq-indexer/indexer/.gitignore (1 hunks)
- packages/rfq-indexer/indexer/.nvmrc (1 hunks)
- packages/rfq-indexer/indexer/.prettier.json (1 hunks)
- packages/rfq-indexer/indexer/abis/FastBridgeV2.ts (1 hunks)
- packages/rfq-indexer/indexer/package.json (1 hunks)
- packages/rfq-indexer/indexer/ponder-env.d.ts (1 hunks)
- packages/rfq-indexer/indexer/ponder.config.ts (1 hunks)
- packages/rfq-indexer/indexer/ponder.schema.ts (1 hunks)
- packages/rfq-indexer/indexer/src/index.ts (1 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/formatAmount.ts (1 hunks)
- packages/rfq-indexer/indexer/src/utils/generateEntryId.ts (1 hunks)
- packages/rfq-indexer/indexer/tsconfig.json (1 hunks)
Files skipped from review due to trivial changes (7)
- packages/rfq-indexer/.dockerignore
- packages/rfq-indexer/.nvmrc
- packages/rfq-indexer/api/.gitignore
- packages/rfq-indexer/indexer/.gitignore
- packages/rfq-indexer/indexer/.nvmrc
- packages/rfq-indexer/indexer/.prettier.json
- packages/rfq-indexer/indexer/ponder-env.d.ts
Additional comments not posted (82)
packages/rfq-indexer/api/.env (1)
2-2: LGTM!The
PORTvariable does not contain sensitive information and can be committed to the repository.packages/rfq-indexer/indexer/src/utils/generateEntryId.ts (1)
1-3: LGTM!The
generateEntryIdfunction correctly generates a unique entry ID by concatenatingchainIdanddbNonceinto a string.packages/rfq-indexer/api/nixpacks.toml (1)
1-4: LGTM!The Nixpacks configuration looks good. It specifies the Node.js provider and defines the necessary installation phase commands to set up the project dependencies using pnpm.
This configuration will help streamline the setup process for developers and ensure consistency in dependency management across different environments.
packages/rfq-indexer/indexer/.eslintrc.json (1)
1-7: LGTM! The ESLint configuration changes are reasonable.The new ESLint configuration file for the
packages/rfq-indexer/indexerdirectory extends the base settings from the "ponder" ESLint configuration, which is a good practice to maintain consistency with the project's coding standards.The
ignorePatternsarray excludes theponder-env.d.tsfile from linting checks, which is reasonable if it contains generated or third-party code that doesn't need to adhere to the project's linting rules.Turning off the
@typescript-eslint/no-unused-varsrule is a matter of preference and coding style. It allows unused variables to be present in the code without triggering linting errors. Developers working on this directory should be aware of this modified linting rule.Overall, the configuration changes will affect the linting process for the files in the
packages/rfq-indexer/indexerdirectory, and developers should take note of these modifications.packages/rfq-indexer/indexer/src/types.ts (1)
3-10: LGTM!The
AddressConfiginterface is well-structured and follows TypeScript best practices. It provides a clear and organized way to manage and utilize address-related configurations within the application.packages/rfq-indexer/indexer/src/utils/formatAmount.ts (1)
1-1: Good choice of library!The
viemlibrary is a reliable and well-tested library for interacting with Ethereum. It provides a convenient way to format amounts using theformatUnitsmethod.packages/rfq-indexer/indexer/.env.example (3)
1-2: Clear and informative comment.The comment provides a concise explanation of the purpose of the RPC URLs and recommends using Alchemy for fetching blockchain data. This helps developers understand the configuration requirements.
3-10: Comprehensive coverage of blockchain networks.The environment variable placeholders cover a wide range of blockchain networks, enabling the application to be configured to connect to multiple networks. This flexibility is essential for an indexer application that needs to fetch data from various sources.
12-13: Flexible database configuration.The optional
DATABASE_URLenvironment variable allows developers to configure the application to use a Postgres database if needed. The fallback to SQLite ensures that the application can still function without a Postgres database, providing flexibility in the database setup.packages/rfq-indexer/indexer/src/utils/chains.ts (2)
1-10: LGTM!The
chainIdToNameobject provides a clean and maintainable way to map chain IDs to their corresponding names. It improves code readability by using descriptive names for the chains and can be easily extended to include additional mappings as needed.
12-14: LGTM!The
getChainNamefunction provides a clean and reusable way to retrieve the chain name associated with a givenchainId. It abstracts away the lookup logic and handles the case when achainIdis not found by returning a default value of 'unknown'.packages/rfq-indexer/api/src/db/index.ts (5)
1-2: Imports look good!The necessary modules from
kyselyandpgpackages are imported correctly.
4-4: Import looks good!The necessary event types are imported correctly from
'../types'.
6-10: Database connection setup looks good!The connection pool is set up correctly using the
DATABASE_URLenvironment variable, and thePostgresDialectinstance is created correctly with the connection pool.
12-18: Database interface looks good!The
Databaseinterface is defined correctly and includes all the necessary event types. The naming of the interface and its properties follows a consistent convention.
20-20: Database instance creation looks good!The
dbinstance is created correctly with theDatabaseinterface and the configureddialect. Exporting thedbinstance allows it to be used in other parts of the application.packages/rfq-indexer/api/src/tsconfig.json (4)
3-5: Great job enabling strict type checking and type-checked indexed access!Strict type checking helps catch potential type-related issues early in the development process, while ensuring type-checked indexed access adds an extra layer of safety to your code.
7-12: The interop constraint options are configured appropriately.Enabling
esModuleInteropandallowSyntheticDefaultImportsensures compatibility with CommonJS modules, while allowing JSON module resolution can be useful for configuration files.
14-19: The language and environment options are set up correctly.Using "bundler" module resolution is suitable for a bundled project. Targeting ES2022 and including the ES2022 lib ensures access to the latest JavaScript features and their type definitions.
24-28: The paths options are configured well.Setting the
baseUrlto the current directory and mapping@/*to./src/*allows for cleaner and more readable import statements throughout the project.packages/rfq-indexer/api/src/graphql/schema.ts (1)
1-24: Well-structured GraphQL schema with modular organization and flexible event handling.The code segment demonstrates a well-organized approach to creating a GraphQL schema. The use of
loadFilesSyncandmergeTypeDefsallows for modular organization of type definitions, improving maintainability and scalability.The introduction of the
BridgeEventunion type is a great addition, as it provides flexibility in handling different event types related to bridge operations. This enhances the API's ability to accommodate diverse event data.The
eventsquery is a convenient way for clients to retrieve a list of events, leveraging theBridgeEventunion type to ensure that the response can include any of the specified event types.Overall, the code segment establishes a solid foundation for the GraphQL schema, promoting modularity, flexibility, and ease of use.
packages/rfq-indexer/indexer/package.json (4)
1-5: LGTM!The project metadata section is appropriately set up for a new internal project, with a valid name, version, private flag, and module type.
19-22: LGTM!The dependencies section is appropriately set up with versioned dependencies using the caret (
^) syntax. Please ensure that the specific versions of@ponder/coreandviemare up to date and compatible with the project's requirements.
23-25: LGTM!The engines section appropriately specifies the required Node.js version, ensuring compatibility and consistency across different setups. Please ensure that the specific version requirement aligns with the project's needs and any other related projects in the monorepo.
26-31: LGTM!The devDependencies section is appropriately set up with type definitions, linting, and TypeScript support. Please ensure that the specific versions of the dev dependencies are up to date and compatible with the project's requirements and other related projects in the monorepo.
packages/rfq-indexer/indexer/tsconfig.json (1)
2-32: LGTM!The TypeScript compiler options are configured appropriately:
- Strict type checking is enabled to catch potential errors early.
- Module interoperability options improve compatibility with JavaScript modules.
- The "bundler" module resolution strategy is suitable for bundled environments.
- Targeting ES2022 ensures that modern JavaScript features are available.
- Skipping type checks for declaration files improves build performance.
packages/rfq-indexer/api/src/utils/overrideJsonBigIntSerialization.ts (1)
1-32: LGTM!The
overrideJsonBigIntSerializationfunction correctly overrides the defaultJSON.stringifymethod to handlebigintvalues. It uses a custom replacer function to convertbigintvalues to integers and allows for filtering of keys based on an optionalreplacerargument. The function maintains the flexibility of the originalJSON.stringifymethod by accommodating both array and function types for thereplacerparameter.The implementation is well-structured and provides a useful utility for serializing
bigintvalues.packages/rfq-indexer/api/package.json (1)
1-41: LGTM! Thepackage.jsonfile is well-structured and comprehensive.The file covers all the essential aspects of the package configuration:
- It defines the package name, version, and main entry point.
- The scripts provide flexibility for running the application in different environments, utilizing
dotenvfor managing environment-specific configurations.- The dependencies include the necessary libraries for building a GraphQL API, such as
express,graphql, and tools from the@graphql-toolssuite.- TypeScript support is incorporated with
ts-nodeandtypescript, ensuring type safety and improving the development experience.- The
enginesfield specifies the required Node.js version, helping maintain consistency across different setups.- The
devDependenciesinclude type definitions for PostgreSQL anddotenv, enhancing type checking capabilities.Overall, this file establishes a robust foundation for developing and running the API service.
packages/rfq-indexer/api/src/graphql/queries/queries.graphql (10)
2-14: LGTM!The
Transactiontype definition is well-structured and captures the essential details of a blockchain transaction. The field names are descriptive, and the types are appropriate. The required fields are marked with the non-null modifier (!).
16-20: LGTM!The
Deposittype definition is well-structured and captures the essential details of a deposit transaction. The field names are descriptive, and the types are appropriate. All fields are marked as required.
22-29: LGTM!The
Relaytype definition is well-structured and captures the essential details of a relay transaction. The field names are descriptive, and the types are appropriate. All fields are marked as required.
31-37: LGTM!The
Prooftype definition is well-structured and captures the essential details of a proof transaction. The field names are descriptive, and the types are appropriate. All fields are marked as required.
39-47: LGTM!The
Claimtype definition is well-structured and captures the essential details of a claim transaction. The field names are descriptive, and the types are appropriate. All fields are marked as required.
49-56: LGTM!The
Refundtype definition is well-structured and captures the essential details of a refund transaction. The field names are descriptive, and the types are appropriate. All fields are marked as required.
61-64: LGTM!The
PendingTransactionMissingRelaytype definition is well-structured and captures the essential details of a pending transaction missing a relay. The field names are descriptive, and the types are appropriate. All fields are marked as required.
66-70: LGTM!The
PendingTransactionMissingProoftype definition is well-structured and captures the essential details of a pending transaction missing a proof. The field names are descriptive, and the types are appropriate. All fields are marked as required.
72-77: LGTM!The
PendingTransactionMissingClaimtype definition is well-structured and captures the essential details of a pending transaction missing a claim. The field names are descriptive, and the types are appropriate. All fields are marked as required.
79-83: LGTM!The
Querytype definition is well-structured and provides fields for querying pending transactions missing relay, proof, or claim. The field names are descriptive, and the return types are appropriate. All fields are marked as required and non-nullable.packages/rfq-indexer/api/src/index.ts (7)
9-9: LGTM!The Express application is created correctly using the
express()function.
11-11: LGTM!The Yoga instance is created correctly using the
createYoga()function with the provided GraphQL schema.
15-17: LGTM!The GET route for the
/api/helloendpoint is defined correctly using theapp.get()method. The route handler sends a JSON response with amessageproperty.
19-27: LGTM!The GET route for the
/api/pending-transactions-missing-relayendpoint is defined correctly using theapp.get()method. The route handler fetches the pending transactions using thependingTransactionsMissingRelayresolver method and sends them as a JSON response. Error handling is implemented using a try-catch block, and a 500 status code is sent in case of an error.
29-37: LGTM!The GET route for the
/api/pending-transactions-missing-proofendpoint is defined correctly using theapp.get()method. The route handler fetches the pending transactions missing proof using thependingTransactionsMissingProofresolver method and sends them as a JSON response. Error handling is implemented using a try-catch block, and a 500 status code is sent in case of an error.
39-47: LGTM!The GET route for the
/api/pending-transactions-missing-claimendpoint is defined correctly using theapp.get()method. The route handler fetches the pending transactions missing claim using thependingTransactionsMissingClaimresolver method and sends them as a JSON response. Error handling is implemented using a try-catch block, and a 500 status code is sent in case of an error.
50-54: LGTM!The Express server is started correctly using the
app.listen()method. The port number is obtained from theprocess.env.PORTenvironment variable, and the callback function logs the URLs for the API server, REST requests, and GraphQL requests.packages/rfq-indexer/api/src/graphql/types/events.graphql (5)
3-21: LGTM!The
BridgeRequestEventtype definition is well-structured and includes all the necessary fields to capture the essential information about a bridge request event. The field names are descriptive, follow a consistent naming convention, and have appropriate types for the data they represent.
23-41: LGTM!The
BridgeRelayedEventtype definition is well-structured and includes all the necessary fields to capture the essential information about a bridge relayed event. The field names are descriptive, follow a consistent naming convention, and have appropriate types for the data they represent.
43-52: LGTM!The
BridgeProofProvidedEventtype definition is well-structured and includes all the necessary fields to capture the essential information about a bridge proof provided event. The field names are descriptive, follow a consistent naming convention, and have appropriate types for the data they represent.
54-66: LGTM!The
BridgeDepositRefundedEventtype definition is well-structured and includes all the necessary fields to capture the essential information about a bridge deposit refunded event. The field names are descriptive, follow a consistent naming convention, and have appropriate types for the data they represent.
68-81: LGTM!The
BridgeDepositClaimedEventtype definition is well-structured and includes all the necessary fields to capture the essential information about a bridge deposit claimed event. The field names are descriptive, follow a consistent naming convention, and have appropriate types for the data they represent.packages/rfq-indexer/indexer/ponder.schema.ts (4)
24-42: LGTM!The
BridgeRelayedEventstable has a well-defined structure with descriptive field names, appropriate types, and no optional fields. This ensures data consistency and ease of understanding.
44-53: Looks good!The
BridgeProofProvidedEventstable is well-structured with descriptive field names, appropriate types, and no optional fields. This ensures data consistency and clarity.
55-67: The table structure looks good!The
BridgeDepositRefundedEventstable is well-organized with descriptive field names, suitable types, and no optional fields. This promotes data consistency and understandability.
69-82: The table is well-structured!The
BridgeDepositClaimedEventstable has a clear structure with descriptive field names, appropriate types, and no optional fields. This ensures data consistency and ease of understanding.packages/rfq-indexer/api/src/types/index.ts (6)
4-22: LGTM!The
BridgeRequestEventsinterface is well-defined with descriptive property names and appropriate types. The use ofColumnTypeensures type safety when interacting with the database.
24-42: LGTM!The
BridgeRelayedEventsinterface follows a structure similar toBridgeRequestEvents, maintaining consistency across bridge event types. The additionalrelayerandtoproperties capture the specific details of a relayed event.
44-53: LGTM!The
BridgeProofProvidedEventsinterface includes a subset of properties from the previous interfaces, focusing on the relevant information for a proof provided event. The inclusion of therelayerproperty captures the key detail of who provided the proof.
55-67: LGTM!The
BridgeDepositRefundedEventsandBridgeDepositClaimedEventsinterfaces follow a consistent structure, capturing the relevant details for deposit refund and claim events. The inclusion of therelayerproperty inBridgeDepositClaimedEventsdistinguishes it from the refund event, indicating the involvement of a relayer in the claim process.Also applies to: 69-82
85-85: LGTM!The
EventTypetype alias provides a clear enumeration of the possible event types, ensuring type safety when working with events. The uppercase naming convention for the values follows a common practice for constant-like values.
87-92: LGTM!The
EventFilterinterface provides a flexible and type-safe way to filter events based on various criteria. The optional properties allow for partial filtering, enabling granular control over the events being queried. The use of theEventTypetype alias for thetypeproperty ensures type safety when specifying the event type filter.packages/rfq-indexer/indexer/src/index.ts (5)
10-53: LGTM!The event handler logic is correct, and the implementation is accurate. The event data is extracted, transformed, and stored in the database correctly.
55-83: LGTM!The event handler logic is correct, and the implementation is accurate. The event data is extracted, transformed, and stored in the database correctly.
85-118: LGTM!The event handler logic is correct, and the implementation is accurate. The event data is extracted, transformed, and upserted in the database correctly. The
upsertmethod is used effectively to handle both creating new records and updating existing ones based on thetransactionId.
120-149: LGTM!The event handler logic is correct, and the implementation is accurate. The event data is extracted, transformed, and stored in the database correctly.
154-197: LGTM!The event handler logic is correct, and the implementation is accurate. The event data is extracted, transformed, and stored in the database correctly.
packages/rfq-indexer/indexer/ponder.config.ts (3)
1-73: LGTM!The code segment correctly sets up the configuration for various blockchain networks and associates each chain ID with its respective details in the
configByChainIdobject.
75-140: LGTM!The
networkDetailsobject is correctly constructed using theconfigByChainIdobject and provides a structured format for each network's details. The object is also properly typed to ensure type safety.
226-226: LGTM!The
configobject is correctly exported as the default export of the module, making it available for use in other parts of the application.packages/rfq-indexer/api/src/graphql/resolvers.ts (6)
146-198: LGTM!The
eventsquery resolver function provides a comprehensive and efficient way to retrieve bridge events with pagination and filtering support. The implementation looks good, and the use of a union query to aggregate data from multiple event tables is a nice approach.
199-217: LGTM!The
pendingTransactionsMissingRelayquery resolver function effectively identifies pending transactions missing relay events. The use of CTEs improves query readability, and joining the relevant tables ensures accurate results. Thenest_resultsfunction enhances the structure and usability of the returned data.
218-236: LGTM!The
pendingTransactionsMissingProofquery resolver function effectively identifies pending transactions missing proof events. The use of CTEs improves query readability, and joining the relevant tables ensures accurate results. Thenest_resultsfunction enhances the structure and usability of the returned data.
237-258: LGTM!The
pendingTransactionsMissingClaimquery resolver function effectively identifies pending transactions missing claim events. The use of CTEs improves query readability, and joining the relevant tables ensures accurate results. Thenest_resultsfunction enhances the structure and usability of the returned data.
261-270: LGTM!The
__resolveTypefunction is a crucial type resolver for theBridgeEventinterface. It effectively determines the specific event type based on the properties of the returned objects, ensuring that the correct event type is returned for each object. This enhances the flexibility and usability of the GraphQL API.
92-142: LGTM!The
nest_resultsutility function effectively restructures the query results into a more organized and readable format. Moving fields with specific suffixes into nested objects improves the clarity and usability of the data, while ensuring that only onetransactionIdfield is included prevents duplication and maintains data consistency. The function is well-structured and easy to understand, enhancing the overall usability of the query results.packages/rfq-indexer/api/src/constants/abis/FastBridgeV2.ts (4)
2-8: LGTM!The constructor is correctly defined with the
constructortype, takes an_ownerparameter of typeaddress, and is appropriately marked as non-payable.
9-112: Great job with the error definitions!The error definitions are comprehensive, covering a wide range of potential error scenarios in the contract. Each error is correctly defined with the
errortype and appropriate parameters. The error names are descriptive and follow a consistent naming convention.
113-244: Excellent work with the event definitions!The event definitions comprehensively cover all the important actions in the contract, such as bridge deposits, proofs, relays, fee updates, and role management. Each event is correctly defined with the
eventtype,anonymousset tofalse, and appropriate parameters. The event names are descriptive and follow a consistent naming convention. The parameter names and types are suitable for each event, and the indexed parameters are correctly specified for efficient event filtering.
245-643: Fantastic work with the function definitions!The function definitions comprehensively cover all the necessary functionalities of the FastBridgeV2 contract, such as bridging, claiming, disputing, proving, refunding, relaying, role management, fee management, and more. Each function is correctly defined with the
functiontype, appropriate visibility, and state mutability. The function names are descriptive and follow a consistent naming convention. The parameter names and types are suitable for each function, and the return types are correctly specified.packages/rfq-indexer/indexer/abis/FastBridgeV2.ts (4)
2-8: LGTM!The constructor correctly initializes the contract with an owner address and is marked as
nonpayable.
9-112: Comprehensive error handling!The ABI defines a wide range of errors covering various failure scenarios. The errors are well-defined, descriptive, and follow a consistent naming convention. This comprehensive error handling enhances the contract's usability and helps users understand the reasons for transaction failures.
113-244: Comprehensive event logging!The ABI defines a wide range of events covering various contract interactions and state changes. The events are well-defined, descriptive, and follow a consistent naming convention. The use of
indexedparameters allows for efficient event filtering and searching. This comprehensive event logging enhances the contract's transparency and traceability.
245-643: Comprehensive functionality!The ABI defines a wide range of functions covering various aspects of cross-chain operations, including bridging, claiming, relaying, disputing, proving, refunding, and managing roles and fees. The functions are well-defined, descriptive, and follow a consistent naming convention. The use of appropriate modifiers ensures that the functions are used correctly and securely. The acceptance and return of complex data types such as structs and tuples enhance the contract's expressiveness and flexibility. This comprehensive functionality provides a solid foundation for managing cross-chain operations.
| export function formatAmount(amount: bigint, tokenAddress: string): string { | ||
| const decimals = tokenAddress.toLowerCase() === ETH_ADDRESS.toLowerCase() ? 18 : 6 | ||
| return formatUnits(amount, decimals) | ||
| } |
There was a problem hiding this comment.
Consider adding a parameter to specify the number of decimal places for non-ETH tokens.
The function assumes 6 decimal places for non-ETH tokens, which may not be accurate for all tokens. Consider adding a parameter to allow specifying the number of decimal places for non-ETH tokens.
Here's an example of how you could modify the function to accept a decimals parameter:
-export function formatAmount(amount: bigint, tokenAddress: string): string {
+export function formatAmount(amount: bigint, tokenAddress: string, decimals = 6): string {
- const decimals = tokenAddress.toLowerCase() === ETH_ADDRESS.toLowerCase() ? 18 : 6
+ const tokenDecimals = tokenAddress.toLowerCase() === ETH_ADDRESS.toLowerCase() ? 18 : decimals
- return formatUnits(amount, decimals)
+ return formatUnits(amount, tokenDecimals)
}This way, the function can still default to 6 decimal places for non-ETH tokens, but also allows specifying a different number of decimal places when needed.
Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export function formatAmount(amount: bigint, tokenAddress: string): string { | |
| const decimals = tokenAddress.toLowerCase() === ETH_ADDRESS.toLowerCase() ? 18 : 6 | |
| return formatUnits(amount, decimals) | |
| } | |
| export function formatAmount(amount: bigint, tokenAddress: string, decimals = 6): string { | |
| const tokenDecimals = tokenAddress.toLowerCase() === ETH_ADDRESS.toLowerCase() ? 18 : decimals | |
| return formatUnits(amount, tokenDecimals) | |
| } |
| "scripts": { | ||
| "test": "echo \"Error: no test specified\" && exit 1", | ||
| "dev:local": "rm -rf .ponder && APP_ENV=local ponder dev", | ||
| "dev": "ponder dev", | ||
| "start": "ponder start", | ||
| "codegen": "ponder codegen", | ||
| "lint": "eslint .", | ||
| "ci:lint": "eslint .", | ||
| "typecheck": "tsc", | ||
| "test:coverage": "echo 'No tests defined.'" | ||
| }, |
There was a problem hiding this comment.
Add actual tests and test coverage reporting.
The test and test:coverage scripts are currently placeholders. Please replace them with actual tests and test coverage reporting to ensure the project's reliability and maintainability.
Defi-Moses
changed the title
There was a problem hiding this comment.
Actionable comments posted: 3
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (8)
- packages/rfq-indexer/README.md (1 hunks)
- packages/rfq-indexer/api/README.md (1 hunks)
- packages/rfq-indexer/api/package.json (1 hunks)
- packages/rfq-indexer/api/src/db/index.ts (1 hunks)
- packages/rfq-indexer/api/src/graphql/schema.ts (1 hunks)
- packages/rfq-indexer/api/src/index.ts (1 hunks)
- packages/rfq-indexer/api/src/types/index.ts (1 hunks)
- packages/rfq-indexer/indexer/README.md (1 hunks)
Files skipped from review due to trivial changes (1)
- packages/rfq-indexer/README.md
Files skipped from review as they are similar to previous changes (5)
- packages/rfq-indexer/api/package.json
- packages/rfq-indexer/api/src/db/index.ts
- packages/rfq-indexer/api/src/graphql/schema.ts
- packages/rfq-indexer/api/src/index.ts
- packages/rfq-indexer/api/src/types/index.ts
Additional context used
LanguageTool
packages/rfq-indexer/indexer/README.md
[uncategorized] ~7-~7: Loose punctuation mark.
Context: ...## Important Scripts -yarn dev:local: Runs the indexer in development mode, c...(UNLIKELY_OPENING_PUNCTUATION)
[style] ~25-~25: Consider shortening or rephrasing this to strengthen your wording.
Context: ... contributing, focus on these files for making changes to the indexing logic, adding new event ty...(MAKE_CHANGES)
packages/rfq-indexer/api/README.md
[uncategorized] ~37-~37: Loose punctuation mark.
Context: ...## Important Scripts -yarn dev:local: Runs the API in development mode using ...(UNLIKELY_OPENING_PUNCTUATION)
Markdownlint
packages/rfq-indexer/api/README.md
14-14: null
Fenced code blocks should have a language specified(MD040, fenced-code-language)
21-21: null
Fenced code blocks should have a language specified(MD040, fenced-code-language)
28-28: null
Fenced code blocks should have a language specified(MD040, fenced-code-language)
Additional comments not posted (1)
packages/rfq-indexer/indexer/README.md (1)
1-24: Well-written documentationThe README.md provides clear instructions and guidance for contributors. The scripts and file descriptions are well-structured and informative.
Tools
LanguageTool
[uncategorized] ~7-~7: Loose punctuation mark.
Context: ...## Important Scripts -yarn dev:local: Runs the indexer in development mode, c...(UNLIKELY_OPENING_PUNCTUATION)
| 4. abis/FastBridgeV2.ts | ||
| - Description: Contains the ABI (Application Binary Interface) for the FastBridgeV2 contract | ||
|
|
||
| When contributing, focus on these files for making changes to the indexing logic, adding new event types, or modifying the database schema. |
There was a problem hiding this comment.
Consider rephrasing for clarity and conciseness
The sentence in line 25 is somewhat lengthy. Rewriting it can make the message stronger and clearer.
Apply this diff to rephrase the sentence:
-When contributing, focus on these files for making changes to the indexing logic, adding new event types, or modifying the database schema.
+Focus on these files to update the indexing logic, add new event types, or modify the database schema.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| When contributing, focus on these files for making changes to the indexing logic, adding new event types, or modifying the database schema. | |
| Focus on these files to update the indexing logic, add new event types, or modify the database schema. |
Tools
LanguageTool
[style] ~25-~25: Consider shortening or rephrasing this to strengthen your wording.
Context: ... contributing, focus on these files for making changes to the indexing logic, adding new event ty...(MAKE_CHANGES)
| ``` | ||
| curl http://localhost:3001/api/pending-transactions-missing-relay | ||
| ``` |
There was a problem hiding this comment.
Specify the language for fenced code blocks.
Markdownlint recommends specifying a language identifier for fenced code blocks to improve syntax highlighting and readability.
Apply the following changes to specify the language for the code blocks:
14,21,28
- ```
+ ```bash
curl http://localhost:3001/api/pending-transactions-missing-relay
Repeat the above change for the code blocks on lines 21-23 and 28-30.
Also applies to: 21-23, 28-30
<details>
<summary>Tools</summary>
<details>
<summary>Markdownlint</summary><blockquote>
14-14: null
Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</blockquote></details>
</details>
<!-- This is an auto-generated comment by CodeRabbit -->
|
|
||
| ## Important Scripts | ||
|
|
||
| - `yarn dev:local`: Runs the API in development mode using local environment variables |
There was a problem hiding this comment.
Add a blank line after the header to fix formatting.
There's a formatting issue due to a missing blank line after the header "## Important Scripts". Markdown requires a blank line after headers to render them properly.
Apply the following change:
35
## Important Scripts
+
37
- `yarn dev:local`: Runs the API in development mode using local environment variablesCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - `yarn dev:local`: Runs the API in development mode using local environment variables | |
| ## Important Scripts | |
| - `yarn dev:local`: Runs the API in development mode using local environment variables |
Tools
LanguageTool
[uncategorized] ~37-~37: Loose punctuation mark.
Context: ...## Important Scripts -yarn dev:local: Runs the API in development mode using ...(UNLIKELY_OPENING_PUNCTUATION)
|
@abtestingalpha to investigate breaking builds |
Defi-Moses
changed the title
trajan0x
changed the title
trajan0x
changed the title
Bundle ReportChanges will decrease total bundle size by 257.69kB (-0.72%) ⬇️. This is within the configured threshold ✅ Detailed changes
ℹ️ *Bundle size includes cached data from a previous commit |
There was a problem hiding this comment.
Actionable comments posted: 5
Outside diff range and nitpick comments (3)
packages/rfq-indexer/api/src/graphql/queries/queries.graphql (3)
62-63: Rename fields to follow lowerCamelCase conventionThe fields
BridgeandBridgeRequestshould be renamed tobridgeandbridgeRequestto maintain consistency with GraphQL naming conventions and other types in your schema.Apply this diff:
type PendingTransactionMissingRelay { - Bridge: Transaction! - BridgeRequest: Deposit! + bridge: Transaction! + bridgeRequest: Deposit! }
67-70: Rename fields to follow lowerCamelCase conventionThe fields
Bridge,BridgeRequest, andBridgeRelayshould be renamed tobridge,bridgeRequest, andbridgeRelayfor consistency.Apply this diff:
type PendingTransactionMissingProof { - Bridge: Transaction! - BridgeRequest: Deposit! - BridgeRelay: Relay! + bridge: Transaction! + bridgeRequest: Deposit! + bridgeRelay: Relay! }
73-77: Rename fields to follow lowerCamelCase conventionThe fields
Bridge,BridgeRequest,BridgeRelay, andBridgeProofshould be renamed tobridge,bridgeRequest,bridgeRelay, andbridgeProofto align with naming conventions.Apply this diff:
type PendingTransactionMissingClaim { - Bridge: Transaction! - BridgeRequest: Deposit! - BridgeRelay: Relay! - BridgeProof: Proof! + bridge: Transaction! + bridgeRequest: Deposit! + bridgeRelay: Relay! + bridgeProof: Proof! }
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (3)
- packages/rfq-indexer/api/src/graphql/queries/queries.graphql (1 hunks)
- packages/rfq-indexer/api/src/graphql/resolvers.ts (1 hunks)
- packages/rfq-indexer/api/src/index.ts (1 hunks)
Files skipped from review as they are similar to previous changes (2)
- packages/rfq-indexer/api/src/graphql/resolvers.ts
- packages/rfq-indexer/api/src/index.ts
| transactionId: String! | ||
| blockNumber: Int! | ||
| blockTimestamp: Int! | ||
| transactionHash: String! | ||
| originChain: String! | ||
| destChain: String! | ||
| originChainId: Int! | ||
| destChainId: Int! | ||
| originToken: String! | ||
| destToken: String! | ||
| originAmountFormatted: String! | ||
| destAmountFormatted: String! | ||
| to: String! | ||
| relayer: String! |
There was a problem hiding this comment.
Reduce duplication by reusing existing Transaction type
The InvalidRelay type duplicates many fields from the Transaction type. To avoid redundancy and improve maintainability, consider including the Transaction type as a field within InvalidRelay.
Apply this change:
type InvalidRelay {
- transactionId: String!
- blockNumber: Int!
- blockTimestamp: Int!
- transactionHash: String!
- originChain: String!
- destChain: String!
- originChainId: Int!
- destChainId: Int!
- originToken: String!
- destToken: String!
- originAmountFormatted: String!
- destAmountFormatted: String!
+ bridge: Transaction!
to: String!
relayer: String!
}Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| transactionId: String! | |
| blockNumber: Int! | |
| blockTimestamp: Int! | |
| transactionHash: String! | |
| originChain: String! | |
| destChain: String! | |
| originChainId: Int! | |
| destChainId: Int! | |
| originToken: String! | |
| destToken: String! | |
| originAmountFormatted: String! | |
| destAmountFormatted: String! | |
| to: String! | |
| relayer: String! | |
| bridge: Transaction! | |
| to: String! | |
| relayer: String! |
| originAmountFormatted: String! | ||
| destAmountFormatted: String! |
There was a problem hiding this comment.
Consider using numerical types for amount fields
Currently, originAmountFormatted and destAmountFormatted are defined as String!. Using a numerical type such as Float! can facilitate numerical operations on the client side and prevent parsing errors.
Apply this diff:
type Transaction {
...
- originAmountFormatted: String!
- destAmountFormatted: String!
+ originAmountFormatted: Float!
+ destAmountFormatted: Float!
...
}Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| originAmountFormatted: String! | |
| destAmountFormatted: String! | |
| originAmountFormatted: Float! | |
| destAmountFormatted: Float! |
|
|
||
| relayer: String! | ||
| to: String! | ||
| amountFormatted: String! |
There was a problem hiding this comment.
Consider using a numerical type for amountFormatted
In the Claim type, amountFormatted is currently a String!. Changing it to a numerical type like Float! may improve data handling.
Apply this diff:
type Claim {
...
- amountFormatted: String!
+ amountFormatted: Float!
...
}Committable suggestion was skipped due to low confidence.
| transactionHash: String! | ||
|
|
||
| to: String! | ||
| amountFormatted: String! |
There was a problem hiding this comment.
Consider using a numerical type for amountFormatted
Similarly, in the Refund type, consider changing amountFormatted from String! to Float! for consistency and better data handling.
Apply this diff:
type Refund {
...
- amountFormatted: String!
+ amountFormatted: Float!
...
}Committable suggestion was skipped due to low confidence.
There was a problem hiding this comment.
Actionable comments posted: 1
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
Files selected for processing (2)
- package.json (2 hunks)
- packages/synapse-interface/package.json (4 hunks)
Files skipped from review as they are similar to previous changes (1)
- packages/synapse-interface/package.json
Additional comments not posted (2)
package.json (2)
9-9: Including 'rfq-indexer' in WorkspacesAdding
"packages/rfq-indexer/*"to thepackagesarray inworkspacessuccessfully integrates therfq-indexerpackage into the monorepo, aligning with the PR objective to consolidate it into the main repository.
77-77: Upgrade to TypeScript 5Upgrading
typescriptto version^5.0.4introduces new features and potential breaking changes. Please verify that all TypeScript code in the project is compatible with this version.
| @@ -73,7 +74,8 @@ | |||
| "ts-mocha": "^10.0.0", | |||
| "typedoc": "^0.23.24", | |||
| "typedoc-plugin-markdown": "^3.14.0", | |||
| "typescript": "^5.0.4" | |||
| "typescript": "^5.0.4", | |||
| "wagmi": "^2.12.12" | |||
There was a problem hiding this comment.
Move 'wagmi' to 'dependencies'
The package wagmi has been added to devDependencies. If wagmi is required at runtime in production code, it should be listed under dependencies to ensure it's included when the application is built.
Apply this diff to move wagmi to dependencies:
"devDependencies": {
...
"typescript": "^5.0.4"
- "wagmi": "^2.12.12"
},
"dependencies": {
"@changesets/cli": "2.22.0",
"eslint-plugin-jsx": "^0.1.0",
+ "wagmi": "^2.12.12"
},
"packageManager": "yarn@1.22.19"Committable suggestion was skipped due to low confidence.
There was a problem hiding this comment.
Actionable comments posted: 5
Outside diff range and nitpick comments (2)
packages/rfq-indexer/api/src/index.ts (2)
20-29: LGTM with a minor suggestion!The endpoint uses an async function to handle the asynchronous nature of the resolver method, which is a good practice. Error handling is implemented to catch any errors and return an appropriate response.
Consider extracting the error handling logic into a separate middleware function to avoid code duplication across multiple endpoints. This will make the code more maintainable and DRY (Don't Repeat Yourself).
31-40: LGTM!The endpoints are well-structured and follow a consistent pattern. They use appropriate HTTP methods (GET) for fetching data, and error handling is implemented consistently across all endpoints.
As mentioned earlier, consider extracting the error handling logic into a separate middleware function to avoid code duplication and improve maintainability.
Also applies to: 42-51, 53-61, 63-71, 73-84, 86-94
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (8)
- packages/rfq-indexer/api/..prettierrc.js (1 hunks)
- packages/rfq-indexer/api/.eslintrc.js (1 hunks)
- packages/rfq-indexer/api/package.json (1 hunks)
- packages/rfq-indexer/api/src/constants/abis/FastBridgeV2.ts (1 hunks)
- packages/rfq-indexer/api/src/constants/networkConfig.ts (1 hunks)
- packages/rfq-indexer/api/src/graphql/queries/queries.graphql (1 hunks)
- packages/rfq-indexer/api/src/graphql/resolvers.ts (1 hunks)
- packages/rfq-indexer/api/src/index.ts (1 hunks)
Files skipped from review due to trivial changes (2)
- packages/rfq-indexer/api/..prettierrc.js
- packages/rfq-indexer/api/.eslintrc.js
Files skipped from review as they are similar to previous changes (4)
- packages/rfq-indexer/api/package.json
- packages/rfq-indexer/api/src/constants/abis/FastBridgeV2.ts
- packages/rfq-indexer/api/src/constants/networkConfig.ts
- packages/rfq-indexer/api/src/graphql/queries/queries.graphql
Additional comments not posted (4)
packages/rfq-indexer/api/src/index.ts (3)
1-8: LGTM!The imports are relevant and serve specific purposes in the application. Overriding JSON serialization for BigInt values is a good practice to ensure proper handling of large numbers.
10-18: LGTM!Setting up an Express app is a standard practice for creating a web server. The
/api/helloendpoint is a simple example that returns a JSON response, which is a good starting point for the API.
96-100: LGTM!Using the
PORTenvironment variable allows flexibility in deploying the application. Logging informative messages is helpful for developers to quickly identify the API endpoints.packages/rfq-indexer/api/src/graphql/resolvers.ts (1)
1-493: Overall, the implementation is comprehensive and aligns with project objectivesThe GraphQL resolvers are well-structured and provide extensive queries for managing bridge-related events. Apart from the noted issues, the code is logically organized and enhances the functionality of the API.
| events: async ( | ||
| _: any, | ||
| { first = 10, after, filter }: { first?: any; after?: any; filter?: any } | ||
| ) => { | ||
| let query = db | ||
| .selectFrom('BridgeRequestEvents') | ||
| .select([ | ||
| 'BridgeRequestEvents.id', | ||
| 'BridgeRequestEvents.transactionId', | ||
| 'BridgeRequestEvents.blockNumber', | ||
| 'BridgeRequestEvents.blockTimestamp', | ||
| 'BridgeRequestEvents.transactionHash', | ||
| 'BridgeRequestEvents.originChainId', | ||
| 'BridgeRequestEvents.originChain', | ||
| ]) | ||
| .unionAll( | ||
| db | ||
| .selectFrom('BridgeRelayedEvents') | ||
| .select([ | ||
| 'BridgeRelayedEvents.id', | ||
| 'BridgeRelayedEvents.transactionId', | ||
| 'BridgeRelayedEvents.blockNumber', | ||
| 'BridgeRelayedEvents.blockTimestamp', | ||
| 'BridgeRelayedEvents.transactionHash', | ||
| 'BridgeRelayedEvents.originChainId', | ||
| 'BridgeRelayedEvents.originChain', | ||
| ]) | ||
| ) | ||
| .unionAll( | ||
| db | ||
| .selectFrom('BridgeProofProvidedEvents') | ||
| .select([ | ||
| 'BridgeProofProvidedEvents.id', | ||
| 'BridgeProofProvidedEvents.transactionId', | ||
| 'BridgeProofProvidedEvents.blockNumber', | ||
| 'BridgeProofProvidedEvents.blockTimestamp', | ||
| 'BridgeProofProvidedEvents.transactionHash', | ||
| 'BridgeProofProvidedEvents.originChainId', | ||
| 'BridgeProofProvidedEvents.originChain', | ||
| ]) | ||
| ) | ||
| .unionAll( | ||
| db | ||
| .selectFrom('BridgeDepositRefundedEvents') | ||
| .select([ | ||
| 'BridgeDepositRefundedEvents.id', | ||
| 'BridgeDepositRefundedEvents.transactionId', | ||
| 'BridgeDepositRefundedEvents.blockNumber', | ||
| 'BridgeDepositRefundedEvents.blockTimestamp', | ||
| 'BridgeDepositRefundedEvents.transactionHash', | ||
| 'BridgeDepositRefundedEvents.originChainId', | ||
| 'BridgeDepositRefundedEvents.originChain', | ||
| ]) | ||
| ) | ||
| .unionAll( | ||
| db | ||
| .selectFrom('BridgeDepositClaimedEvents') | ||
| .select([ | ||
| 'BridgeDepositClaimedEvents.id', | ||
| 'BridgeDepositClaimedEvents.transactionId', | ||
| 'BridgeDepositClaimedEvents.blockNumber', | ||
| 'BridgeDepositClaimedEvents.blockTimestamp', | ||
| 'BridgeDepositClaimedEvents.transactionHash', | ||
| 'BridgeDepositClaimedEvents.originChainId', | ||
| 'BridgeDepositClaimedEvents.originChain', | ||
| ]) | ||
| ) | ||
|
|
||
| if (filter) { | ||
| if (filter.transactionId) { | ||
| query = query.where('transactionId', '=', filter.transactionId) | ||
| } | ||
| if (filter.originChainId) { | ||
| query = query.where('originChainId', '=', filter.originChainId) | ||
| } | ||
| // Add more filters as needed | ||
| } | ||
|
|
||
| if (after) { | ||
| query = query.where('id', '>', after) | ||
| } | ||
|
|
||
| const events = await query | ||
| .orderBy('blockTimestamp', 'desc') | ||
| .limit(first + 1) | ||
| .execute() | ||
|
|
||
| const hasNextPage = events.length > first | ||
| const edges = events.slice(0, first).map((event: any) => ({ | ||
| node: event, | ||
| cursor: event.id, | ||
| })) | ||
|
|
||
| return { | ||
| edges, | ||
| pageInfo: { | ||
| hasNextPage, | ||
| endCursor: edges.length > 0 ? edges[edges.length - 1]?.cursor : null, | ||
| }, | ||
| } |
There was a problem hiding this comment.
Refactor union queries to reduce code duplication
The events resolver constructs multiple unionAll queries that have similar structures and select statements. This repetition can make the code harder to maintain and more prone to errors.
Consider creating a helper function that generates the select statements for each event table. This will reduce duplication and improve the maintainability of the code.
Example refactor:
// Define a helper function to generate the select queries
const selectEventFields = (tableName: string) => [
`${tableName}.id`,
`${tableName}.transactionId`,
`${tableName}.blockNumber`,
`${tableName}.blockTimestamp`,
`${tableName}.transactionHash`,
`${tableName}.originChainId`,
`${tableName}.originChain`,
]
// Use the helper function in the resolver
...
.select(selectEventFields('BridgeRequestEvents'))
...| const nest_results = (sqlResults: any[]) => { | ||
| return sqlResults.map((transaction: any) => { | ||
| const bridgeRequest: { [key: string]: any } = {} | ||
| const bridgeRelay: { [key: string]: any } = {} | ||
| const bridgeProof: { [key: string]: any } = {} | ||
| const bridgeClaim: { [key: string]: any } = {} | ||
| const bridgeRefund: { [key: string]: any } = {} | ||
| const bridgeDispute: { [key: string]: any } = {} | ||
| const transactionFields: { [key: string]: any } = {} | ||
|
|
||
| let transactionIdSet = false | ||
|
|
||
| for (const [key, value] of Object.entries(transaction)) { | ||
| if (key.startsWith('transactionId')) { | ||
| if (!transactionIdSet) { | ||
| transactionFields[key.replace(/_.+$/, '')] = value | ||
| transactionIdSet = true | ||
| } | ||
| // Ignore other transactionId fields | ||
| } else if (key.endsWith('_deposit')) { | ||
| bridgeRequest[key.replace('_deposit', '')] = value | ||
| } else if (key.endsWith('_relay')) { | ||
| bridgeRelay[key.replace('_relay', '')] = value | ||
| } else if (key.endsWith('_proof')) { | ||
| bridgeProof[key.replace('_proof', '')] = value | ||
| } else if (key.endsWith('_claim')) { | ||
| bridgeClaim[key.replace('_claim', '')] = value | ||
| } else if (key.endsWith('_refund')) { | ||
| bridgeRefund[key.replace('_refund', '')] = value | ||
| } else if (key.endsWith('_dispute')) { | ||
| bridgeDispute[key.replace('_dispute', '')] = value | ||
| } else { | ||
| transactionFields[key] = value | ||
| } | ||
| } | ||
|
|
||
| const result: { [key: string]: any } = { Bridge: transactionFields } | ||
| if (Object.keys(bridgeRequest).length) { | ||
| result.BridgeRequest = bridgeRequest | ||
| } | ||
| if (Object.keys(bridgeRelay).length) { | ||
| result.BridgeRelay = bridgeRelay | ||
| } | ||
| if (Object.keys(bridgeProof).length) { | ||
| result.BridgeProof = bridgeProof | ||
| } | ||
| if (Object.keys(bridgeClaim).length) { | ||
| result.BridgeClaim = bridgeClaim | ||
| } | ||
| if (Object.keys(bridgeRefund).length) { | ||
| result.BridgeRefund = bridgeRefund | ||
| } | ||
| if (Object.keys(bridgeDispute).length) { | ||
| result.BridgeDispute = bridgeDispute | ||
| } | ||
| return result | ||
| }) | ||
| } |
There was a problem hiding this comment.
Optimize the nest_results function for better performance
The nest_results function uses multiple objects and loops to transform the SQL results. This can be optimized to improve performance and readability.
Consider using a more efficient mapping strategy or utility library to handle the nesting and transformation of the results.
| __resolveType(obj: any) { | ||
| // Implement logic to determine the event type based on the object properties | ||
| // For example: | ||
| if ('sender' in obj) { | ||
| return 'BridgeRequestEvent' | ||
| } | ||
| if ('relayer' in obj && 'to' in obj) { | ||
| return 'BridgeRelayedEvent' | ||
| } | ||
| if ('relayer' in obj && !('to' in obj)) { | ||
| return 'BridgeProofProvidedEvent' | ||
| } | ||
| if ('to' in obj && 'token' in obj) { | ||
| return 'BridgeDepositRefundedEvent' | ||
| } | ||
| if ('relayer' in obj && 'to' in obj && 'token' in obj) { | ||
| return 'BridgeDepositClaimedEvent' | ||
| } | ||
| return null | ||
| }, |
There was a problem hiding this comment.
Fix condition ordering in __resolveType to ensure accurate type resolution
The __resolveType function may incorrectly identify event types due to the order of conditions. For instance, an object with 'relayer', 'to', and 'token' properties intended to be a BridgeDepositClaimedEvent might be incorrectly identified as a BridgeRelayedEvent because that condition is evaluated first.
To resolve this issue, reorder the conditions so that more specific checks come before general ones.
Apply this diff to reorder the conditions:
__resolveType(obj: any) {
// Implement logic to determine the event type based on the object properties
// For example:
+ if ('relayer' in obj && 'to' in obj && 'token' in obj) {
+ return 'BridgeDepositClaimedEvent'
+ }
+ if ('to' in obj && 'token' in obj) {
+ return 'BridgeDepositRefundedEvent'
+ }
if ('sender' in obj) {
return 'BridgeRequestEvent'
}
if ('relayer' in obj && 'to' in obj) {
return 'BridgeRelayedEvent'
}
if ('relayer' in obj && !('to' in obj)) {
return 'BridgeProofProvidedEvent'
}
- if ('to' in obj && 'token' in obj) {
- return 'BridgeDepositRefundedEvent'
- }
return null
}Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| __resolveType(obj: any) { | |
| // Implement logic to determine the event type based on the object properties | |
| // For example: | |
| if ('sender' in obj) { | |
| return 'BridgeRequestEvent' | |
| } | |
| if ('relayer' in obj && 'to' in obj) { | |
| return 'BridgeRelayedEvent' | |
| } | |
| if ('relayer' in obj && !('to' in obj)) { | |
| return 'BridgeProofProvidedEvent' | |
| } | |
| if ('to' in obj && 'token' in obj) { | |
| return 'BridgeDepositRefundedEvent' | |
| } | |
| if ('relayer' in obj && 'to' in obj && 'token' in obj) { | |
| return 'BridgeDepositClaimedEvent' | |
| } | |
| return null | |
| }, | |
| __resolveType(obj: any) { | |
| // Implement logic to determine the event type based on the object properties | |
| // For example: | |
| if ('relayer' in obj && 'to' in obj && 'token' in obj) { | |
| return 'BridgeDepositClaimedEvent' | |
| } | |
| if ('to' in obj && 'token' in obj) { | |
| return 'BridgeDepositRefundedEvent' | |
| } | |
| if ('sender' in obj) { | |
| return 'BridgeRequestEvent' | |
| } | |
| if ('relayer' in obj && 'to' in obj) { | |
| return 'BridgeRelayedEvent' | |
| } | |
| if ('relayer' in obj && !('to' in obj)) { | |
| return 'BridgeProofProvidedEvent' | |
| } | |
| return null | |
| }, |
| ) => { | ||
| const query = db | ||
| .with('deposits', () => | ||
| qDeposits().where('transactionId', '=', transactionId) | ||
| ) | ||
| .with('relays', () => qRelays()) | ||
| .with('proofs', () => qProofs()) | ||
| .with('claims', () => qClaims()) | ||
| .with('refunds', () => qRefunds()) | ||
| .with('combined', (qb) => | ||
| qb | ||
| .selectFrom('deposits') | ||
| .leftJoin('relays', 'transactionId_deposit', 'transactionId_relay') | ||
| .leftJoin('proofs', 'transactionId_deposit', 'transactionId_proof') | ||
| .leftJoin('claims', 'transactionId_deposit', 'transactionId_claim') | ||
| .leftJoin( | ||
| 'refunds', | ||
| 'transactionId_deposit', | ||
| 'transactionId_refund' | ||
| ) | ||
| .selectAll('deposits') | ||
| .selectAll('relays') | ||
| .selectAll('proofs') | ||
| .selectAll('claims') | ||
| .selectAll('refunds') | ||
| ) | ||
| .selectFrom('combined') | ||
| .selectAll() | ||
|
|
||
| const nestedResult = nest_results(await query.execute())[0] || null | ||
|
|
||
| if (nestedResult) { | ||
| return Object.fromEntries( | ||
| Object.entries(nestedResult).filter(([_, value]) => { | ||
| if (value === null) { | ||
| return false | ||
| } | ||
| if (typeof value !== 'object') { | ||
| return true | ||
| } | ||
| return Object.values(value).some((v) => v !== null) | ||
| }) | ||
| ) | ||
| } | ||
|
|
||
| return null | ||
| }, | ||
| conflictingProofs: async () => { | ||
| const query = db | ||
| .with('deposits', () => qDeposits()) | ||
| .with('relays', () => qRelays()) | ||
| .with('proofs', () => qProofs()) | ||
| .with('combined', (qb) => | ||
| qb | ||
| .selectFrom('deposits') | ||
| .leftJoin('relays', 'transactionId_deposit', 'transactionId_relay') | ||
| .leftJoin('proofs', 'transactionId_deposit', 'transactionId_proof') | ||
| .selectAll('deposits') | ||
| .selectAll('relays') | ||
| .selectAll('proofs') | ||
| ) | ||
| .selectFrom('combined') | ||
| .selectAll() | ||
| .where('relayer_proof', 'is not', null) | ||
| .where('relayer_relay', 'is not', null) | ||
| .where( | ||
| (eb) => | ||
| sql<boolean>`LOWER(${eb.ref('relayer_relay')}) != LOWER(${eb.ref( | ||
| 'relayer_proof' | ||
| )})` | ||
| ) | ||
| .orderBy('blockTimestamp_proof', 'desc') | ||
|
|
||
| return nest_results(await query.execute()) | ||
| }, | ||
| }, | ||
| BridgeEvent: { | ||
| // eslint-disable-next-line prefer-arrow/prefer-arrow-functions | ||
| __resolveType(obj: any) { | ||
| // Implement logic to determine the event type based on the object properties | ||
| // For example: | ||
| if ('sender' in obj) { | ||
| return 'BridgeRequestEvent' | ||
| } | ||
| if ('relayer' in obj && 'to' in obj) { | ||
| return 'BridgeRelayedEvent' | ||
| } | ||
| if ('relayer' in obj && !('to' in obj)) { | ||
| return 'BridgeProofProvidedEvent' | ||
| } | ||
| if ('to' in obj && 'token' in obj) { | ||
| return 'BridgeDepositRefundedEvent' | ||
| } | ||
| if ('relayer' in obj && 'to' in obj && 'token' in obj) { | ||
| return 'BridgeDepositClaimedEvent' | ||
| } | ||
| return null | ||
| }, | ||
| }, | ||
| } |
There was a problem hiding this comment.
Enhance type safety by specifying TypeScript types
The resolver functions currently use the any type for parameters and return values, which defeats the purpose of TypeScript's type safety features.
Define appropriate types or interfaces for the resolver arguments and return values to leverage TypeScript's compile-time checks and improve code reliability.
Example modification:
const resolvers = {
Query: {
- events: async (
- _: any,
- { first = 10, after, filter }: { first?: any; after?: any; filter?: any }
- ) => {
+ events: async (
+ _: unknown,
+ {
+ first = 10,
+ after,
+ filter,
+ }: {
+ first?: number
+ after?: number
+ filter?: {
+ transactionId?: string
+ originChainId?: number
+ }
+ }
+ ): Promise<EventConnection> => {
// Resolver implementation...Define the EventConnection type and any other custom types used in your resolvers.
Committable suggestion was skipped due to low confidence.
| 'BridgeRequestEvents.sender', | ||
| 'BridgeRequestEvents.sendChainGas', | ||
| ]) | ||
| .where('BridgeRequestEvents.blockTimestamp', '>', 1722729600) |
There was a problem hiding this comment.
Tip
Codebase Verification
Review the hardcoded timestamp and consider a more dynamic approach
The hardcoded timestamp (1722729600) in ./packages/rfq-indexer/api/src/graphql/resolvers.ts corresponds to August 3, 2024. Given that the current date is September 2024, this filter might be excluding relevant data.
Consider the following:
- Review and update the timestamp if necessary to include all relevant data.
- Implement a more dynamic approach for setting this cutoff date, such as using a relative time period (e.g., "3 months ago") or a configurable value.
- If the specific date (August 3, 2024) is intentional, add a comment explaining its significance for future maintenance.
The nearby comments suggest this is related to limiting lookback due to partial index loading, but they don't explain the choice of this specific date.
Analysis chain
Verify the hardcoded timestamp in the query filter
The qDeposits function filters events with a blockTimestamp greater than 1722729600, which corresponds to August 3, 2024. Since the current date is September 2024, this filter might exclude intended data or may not be necessary anymore.
Please verify if this hardcoded timestamp is still required or if it should be updated or removed.
To check the earliest blockTimestamp in BridgeRequestEvents, run:
Replace db-query with the appropriate command to query your database.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Retrieve the minimum blockTimestamp in BridgeRequestEvents
echo "Minimum blockTimestamp in BridgeRequestEvents:"
db-query 'SELECT MIN(blockTimestamp) FROM BridgeRequestEvents;'
Length of output: 244
Script:
#!/bin/bash
# Search for the hardcoded timestamp across the codebase
echo "Files containing the hardcoded timestamp 1722729600:"
rg -n "1722729600" --type-not binary
echo "\nComments or documentation related to the timestamp:"
rg -n "1722729600" --type-not binary -C 2 | rg "//|/\*|\*"
echo "\nPotential configuration files or constants defining the timestamp:"
rg -n "1722729600" --type-not binary | rg "\.(js|ts|json|yaml|yml|env)$"
Length of output: 640
Script:
#!/bin/bash
# Search for the hardcoded timestamp across the codebase using grep
echo "Files containing the hardcoded timestamp 1722729600:"
grep -rn "1722729600" . --exclude-dir={node_modules,dist,build} --exclude=*.{jpg,png,gif,svg,woff,ttf}
echo -e "\nComments or documentation related to the timestamp:"
grep -rn -C 2 "1722729600" . --exclude-dir={node_modules,dist,build} --exclude=*.{jpg,png,gif,svg,woff,ttf} | grep -E "//|/\*|\*"
echo -e "\nPotential configuration files or constants defining the timestamp:"
grep -rn "1722729600" . --include=*.{js,ts,json,yaml,yml,env} --exclude-dir={node_modules,dist,build}
Length of output: 1530
* update bl * remove global solidity extension settings * use monorepo support in global workspace only * - use Solidity extension for formatting *.sol files - use `forge fmt` as formatter in Solidity extension * REST API Improvements [SLT-179] (#3133) * fix swaptxinfo function * Updates test coverage command * migrating to using token addresses instead of symbols * fix linting errors * fixing swaptxinfocontroller * new tests and new functionality --------- Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> * Publish - @synapsecns/rest-api@1.0.75 - @synapsecns/synapse-interface@0.38.4 * fix harmony proxy (#3149) Co-authored-by: Trajan0x <trajan0x@users.noreply.github.com> * merging rfq indexer into monorepo [SLT-164] [SLT-176] (#3136) * merging rfq indexer into monorepo * nuke .env * fix commands * fix package name * test coverage script * rough pass at docs and some linting and fixes yarn * Upgrades wagmi & rainbowkit * indxer * Adds invisible but used packages * +recent-invalid-fills [SLT-188] * Moves wagmi to root * new endpoints and clean up linting --------- Co-authored-by: Trajan0x <trajan0x@users.noreply.github.com> Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> Co-authored-by: parodime <jordan@protochainresearch.com> * Publish - @synapsecns/synapse-interface@0.38.5 - @synapsecns/rfq-indexer-api@1.0.2 - @synapsecns/rfq-indexer@0.0.2 * Adds /destinationTokens route [SLT-204] (#3151) * Adds /destinationTokens route * ZeroAddress & NativeGasAddress * Adds test for native gas tokens * Checksums incoming token address params * Publish - @synapsecns/rest-api@1.0.76 * boba pause (#3150) * boba pause * only boba to txns * Publish - @synapsecns/synapse-interface@0.38.6 * fix(synapse-interface): Reorders validation to check existence first (#3156) * Reorders validation to check existence first * Removes duplicates * Publish - @synapsecns/rest-api@1.0.77 * Fix boba pause (#3158) * Publish - @synapsecns/synapse-interface@0.38.7 * update bl * feat(rest-api): Adds Swagger for api docs [SLT-205] (#3159) * Adds Swagger for api docs * Replace prepended verb Get routes with nouns * Adds dev flag for swagger serverUrl * Publish - @synapsecns/rest-api@1.1.0 - @synapsecns/synapse-interface@0.38.8 - @synapsecns/rfq-indexer-api@1.0.3 - @synapsecns/rfq-indexer@0.0.3 * Pulls version from package json (#3160) * Publish - @synapsecns/rest-api@1.1.1 * Require vs import due to file location (#3161) * Require vs import due to file location * Publish - @synapsecns/rest-api@1.1.2 * Prevent caching of api docs (#3162) * Publish - @synapsecns/rest-api@1.1.3 * feat(contracts-rfq): relay/prove/claim with different address [SLT-130] (#3138) * init. solidity ^. FbV2 relay/prove/claim overloads * +IFastBridgeV2, explicit address0 cast, func scope & inheritdoc fixes * pragma lock, contract relabel * feat: start scoping V2 tests * test: override relayer role scenarios, no longer enforced by V2 * test: finish the parity test * test: the management methods * test: dst chain scenarios * test: bridge * test: prove * test: claim * test: dispute * test: refund * test: bridge reverts * remove redundant extend. rearrange inherit list * revert 0.8.20 in favor of user (non-ws) setting --------- Co-authored-by: ChiTimesChi <88190723+ChiTimesChi@users.noreply.github.com> * Publish - FastBridge@0.4.0 * fix(promexporter): make spans better (#3164) * move the errors * [goreleaser] * fix v to w * changing native token address standard [SLT-210] (#3157) * changing native token address standard * fixing tests * normalizeNativeTokenAddress middleware, additional tests --------- Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> * Publish - @synapsecns/rest-api@1.1.4 * Refactoring rfq-indexer API and adding swagger docs [SLT-228] (#3167) * refactoring and adding swagger * remove testing scripts * fix typos and consistency with 404 errors * Publish - @synapsecns/rfq-indexer-api@1.0.4 * fix read mes (#3168) * Publish - @synapsecns/contracts-core@1.0.32 - FastBridge@0.4.1 - @synapsecns/solidity-devops@0.4.5 * fix(opbot): use submitter get tx status [SLT-158] (#3134) * use experimental logger to debug * fix lint * [goreleaser] * use submitter instead of client * [goreleaser] * [goreleaser] * fix(synapse-interface): Additional checks on screen [SLT-166] (#3152) * Additional checks on screen * Adds checks on chain/token changes * Publish - @synapsecns/synapse-interface@0.38.9 * feat(synapse-interface): confirm new price [SLT-150] (#3084) * add bridge quote history middleware * request user confirm changes when quoted price updates * add conditions for displaying confirm change state * track initial quote initializing confirm change state * specify output delta threshold * callback functions to handle initialize/accept/reset confirm changes flow * quote countdown timer animation to signal refresh * implement automatic refresh intervals * mouse move to refresh automatic intervals * add i8n translations for button text --------- Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> * Publish - @synapsecns/synapse-interface@0.39.0 * fix: formatted bridge fee amount (#3165) * Publish - @synapsecns/rest-api@1.1.5 * fix(contracts-rfq): CI workflows [SLT-245] (#3178) * fix: license, files * fix: package name * build: update solhint to latest * build: remove prettier dependencies * fix: solhint workflows * build: update solhint in other packages as well * chore: solhint rules, exceptions * fix: silence linter warnings in tests * chore: forge fmt * add variable to test linter CI * Revert "add variable to test linter CI" This reverts commit 0629309. * Publish - @synapsecns/contracts-core@1.0.33 - @synapsecns/contracts-rfq@0.5.0 - @synapsecns/solidity-devops@0.4.6 * feat(api): bridge limits [SLT-165] (#3179) * adds `/bridgeLimits` route, controller * fetch best sdk quote for min/max origin amounts * add tests * implement middleware to normalize addresses * adds swagger doc * Publish - @synapsecns/rest-api@1.2.0 * fix(contracts-rfq): limit the amount of solhint warnings [SLT-245] (#3182) * ci: limit the amount of solhint warnings * refactor: move the errors into the separate interface * refactor: errors imports in tests * Publish - @synapsecns/contracts-rfq@0.5.1 * ci: Solidity gas diff [SLT-259] (#3181) * ci: run tests w/o coverage first for better visibility * test: malform the test to check the adjusted workflow * Revert "test: malform the test to check the adjusted workflow" This reverts commit e7db6e1. * ci: add gas-diff workflow * try changing the contract to trigger gas diffs * retrigger the workflow * ci: provide the correct report path * ci: run on pull requests only * ci: save gas reports in monorepo root * Revert "ci: run on pull requests only" This reverts commit 0a01d60. * Revert "try changing the contract to trigger gas diffs" This reverts commit 91bc03e. * refactor: wrap if statement * refactor: exclude `solidity-devops` package in a more generic way * ci: run tests w/o coverage for `solidity-devops`, add comments * add generic comment to trigger `solidity-devops` workflows * Revert "add generic comment to trigger `solidity-devops` workflows" This reverts commit cc35a43. * Publish - @synapsecns/contracts-rfq@0.5.2 * fix(contracts-core): set very high gas limit for intensive tests [SLT-259] (#3186) * fix: set very high gas limit for intensive tests * ci: speed up solidity coverage * Publish - @synapsecns/contracts-core@1.0.34 * feat(rest-api): Adds validateRouteExists validation [SLT-260] (#3180) * Adds validateRouteExists validation * Remove timeouts for 400s * Publish - @synapsecns/rest-api@1.3.0 * add duplicate command warning (#3174) Co-authored-by: Trajan0x <trajan0x@users.noreply.github.com> * reduce solhint warnings on FbV2 (#3189) * reduce solhint warnings on FbV2 * fix whitespace * Publish - @synapsecns/contracts-rfq@0.5.3 * ci: solidity gas diff options [SLT-267] (#3193) * ci: ignore test files in gas diff report * add some changes to the test files * ci: define some options for gas-diff * try changing the contract to trigger gas diffs * Revert "try changing the contract to trigger gas diffs" This reverts commit 4504e3c. * Revert "add some changes to the test files" This reverts commit 7e7d6cb. * prove w/ tx id [SLT-181] (#3169) * prove w/ tx id SLT-181 * +proveOther tests, forge fmt * fmt * fmt * Publish - @synapsecns/contracts-rfq@0.5.4 * fix(sdk-router): disable ARB airdrop tests (#3195) * Publish - @synapsecns/rest-api@1.3.1 - @synapsecns/sdk-router@0.11.2 - @synapsecns/synapse-interface@0.39.1 - @synapsecns/widget@0.7.2 * Fixing issue for wallet integration [SLT-270] (#3194) * slight modification to graphql call * fixing explorer frontend as well * Publish - @synapsecns/explorer-ui@0.3.3 - @synapsecns/rest-api@1.3.2 * store relayer on relay [SLT-182] (#3170) * store relayer on relay [SLT-182] * +tests, zeroAddr check, fmt * Publish - @synapsecns/contracts-rfq@0.5.5 * Adjust text to trigger build (#3199) * Publish - @synapsecns/synapse-interface@0.39.2 * feat(synapse-interface): refund RFQ transaction [SLT-272] (#3197) * Txn transaction refund tracking * Update store to support tracking * Query FastBridge contract for `bridgeStatuses` to find refund status * Track bridge transaction `bridgeQuote.routerAddress` in store * Fetch FastBridge contract address when only provided router address * add translations --------- Co-authored-by: aureliusbtc <82057759+aureliusbtc@users.noreply.github.com> Co-authored-by: ChiTimesChi <88190723+ChiTimesChi@users.noreply.github.com> Co-authored-by: abtestingalpha <abtestingalpha@gmail.com> Co-authored-by: Defi-Moses <Defi-Moses@users.noreply.github.com> Co-authored-by: trajan0x <83933037+trajan0x@users.noreply.github.com> Co-authored-by: Trajan0x <trajan0x@users.noreply.github.com> Co-authored-by: parodime <jordan@protochainresearch.com> Co-authored-by: abtestingalpha <104046418+abtestingalpha@users.noreply.github.com> Co-authored-by: abtestingalpha <abtestingalpha@users.noreply.github.com> Co-authored-by: parodime <parodime@users.noreply.github.com> Co-authored-by: vro <168573323+golangisfun123@users.noreply.github.com> Co-authored-by: ChiTimesChi <ChiTimesChi@users.noreply.github.com> Co-authored-by: bigboydiamonds <57741810+bigboydiamonds@users.noreply.github.com> Co-authored-by: bigboydiamonds <bigboydiamonds@users.noreply.github.com>
Moves the rfq-indexer into the main monorepo.
Summary by CodeRabbit
New Features
Configuration
rfq-indexerpackage in workspace configurations to improve organization and dependency management.package.jsonfiles for therfq-indexerproject and its API, defining essential scripts and dependencies.Documentation
README.mdfor the RFQ Indexer, outlining key scripts and project structure for better contributor guidance.Dependency Updates
synapse-interfacepackage to improve functionality and stability.bc96018: synapse-interface preview link
88b746a: synapse-interface preview link
41add40: synapse-interface preview link