[IND-519] upgrade Indexer cosmos dependency versions #888
Conversation
WalkthroughThe updates across various TypeScript files in the dydxprotocol codebase reflect a significant reorganization and renaming of entities, particularly related to rate limiting and liquidations. Deprecated elements have been removed, and there's a shift towards a more consistent naming convention, favoring camelCase over snake_case. The restructuring also includes the introduction of new interfaces and classes to handle queries and message services, indicating an expansion or refinement of the protocol's capabilities. Changes
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 X ? TipsChat with CodeRabbit Bot (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 5
Configuration used: CodeRabbit UI
Files ignored due to filter (2)
- indexer/packages/v4-protos/package.json
- indexer/pnpm-lock.yaml
Files selected for processing (15)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/bundle.ts (6 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/clob/liquidations.ts (2 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/capacity.ts (1 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/genesis.ts (1 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/limit_params.ts (1 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/query.lcd.ts (1 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/query.rpc.Query.ts (1 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/query.ts (1 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/tx.rpc.msg.ts (1 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/tx.ts (1 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/indexer/events/events.ts (2 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/lcd.ts (1 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/perpetuals/perpetual.ts (2 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/rpc.query.ts (1 hunks)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/rpc.tx.ts (1 hunks)
Files skipped from review due to trivial changes (2)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/indexer/events/events.ts
- indexer/packages/v4-protos/src/codegen/dydxprotocol/perpetuals/perpetual.ts
Additional comments: 17
indexer/packages/v4-protos/src/codegen/dydxprotocol/bundle.ts (4)
- 42-67: <!--Monologue:
Thought 1: The files within the 'ibcratelimit' directory do exist, as evidenced by the output of thefdcommand.
Reflect 1: This confirms that the directory and its files have been created or renamed correctly as part of the changes.Thought 2: The
rgcommands have found references to the renamed modules in various files, including thebundle.tsfile and others likequery.lcd.ts,rpc.query.ts,lcd.ts, andrpc.tx.ts.
Reflect 2: This indicates that the references to the modules have been updated in these files to reflect the new import paths.Thought 3: Since there were no matches for the old import paths and the new paths are being referenced correctly, it seems that the changes have been implemented consistently across the codebase.
Reflect 3: I can conclude that the renaming and reorganization of the imports related to the 'ibcratelimit' directory have been verified and are consistent with the changes described in the PR.
-->The verification process has confirmed that:
- The files within the 'ibcratelimit' directory exist and have been correctly created or renamed.
- References to the renamed modules have been updated in various files across the codebase, including
bundle.ts,query.lcd.ts,rpc.query.ts,lcd.ts, andrpc.tx.ts.Based on the information gathered, the changes related to the renaming and reorganization of imports in
bundle.tsare consistent with the rest of the codebase.Analysis chain
The imports from "./ratelimit" have been renamed to "./ibcratelimit" and new imports have been added. Ensure that all references to these modules throughout the codebase have been updated to reflect the new import paths.
To verify the changes thoroughly, I will perform the following steps:
- Check if the files within the
ibcratelimitdirectory exist, as they should be present after the renaming.- Search for any references to the specific modules that were renamed (e.g.,
capacity,genesis,limit_params,query,tx) to ensure they have been updated throughout the codebase.* 42-67: Reordering of imports within namespaces has been performed. Verify that this reordering does not introduce circular dependencies or other import-related issues.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for old import paths to ensure they have been replaced. rg 'from "./ratelimit"' --files-with-matches # Search for new import paths to ensure they are being used correctly. rg 'from "./ibcratelimit"' --files-with-matchesLength of output: 96
Script:
#!/bin/bash # Check if the files within the 'ibcratelimit' directory exist. fd --type f --full-path './src/codegen/dydxprotocol/ibcratelimit/' # Search for references to the specific modules that were renamed to ensure they have been updated. rg 'ibcratelimit/capacity' --files-with-matches rg 'ibcratelimit/genesis' --files-with-matches rg 'ibcratelimit/limit_params' --files-with-matches rg 'ibcratelimit/query' --files-with-matches rg 'ibcratelimit/tx' --files-with-matchesLength of output: 1494
- 211-218: The output from the scripts indicates that the
ibcratelimitnamespace is being used across multiple files within thev4-protospackage. The usage includes creating new instances of clients, making RPC requests, and referencing endpoints. Here's a summary of the usage in each file:
rpc.query.ts: Theibcratelimitnamespace is used to create a new RPC query extension.lcd.ts: Theibcratelimitnamespace is used to create a new LCD query client.ibcratelimit/tx.rpc.msg.ts: The namespace is used in RPC requests for setting and deleting limit parameters.ibcratelimit/query.rpc.Query.ts: The namespace is used in RPC requests for listing limit parameters and querying capacity by denom.ibcratelimit/query.lcd.ts: The namespace is used in endpoint URLs for listing limit parameters and querying capacity by denom.ibcratelimit/genesis.ts: The namespace is mentioned in comments describing the genesis state of theibcratelimitmodule.The consistent use of the
ibcratelimitnamespace across these files suggests that the changes made in thebundle.tsfile have been correctly propagated and are being utilized as intended throughout the codebase. There are no indications of incorrect usage or inconsistencies based on the provided outputs.Based on the information gathered, it appears that the new namespace
ibcratelimithas been added and is being used correctly in the rest of the codebase. The new structure is reflected in all relevant parts of the application where the namespace is referenced.Analysis chain
The new namespace
ibcratelimithas been added, and several namespaces have been expanded with new imports. Ensure that these namespaces are correctly used in the rest of the codebase and that the new structure is reflected in all relevant parts of the application.
The search results indicate that the new
ibcratelimitnamespace is being used in several files within thev4-protospackage of the Indexer project. The files listed are where the namespace is referenced, which suggests that the changes made in thebundle.tsfile are being utilized elsewhere in the codebase.To ensure that the usage of the
ibcratelimitnamespace is correct and consistent, we should check if the namespace is being imported and used as intended in these files. This would involve looking for the import statements and the usage of the namespace in the code to verify that it aligns with the changes made inbundle.ts.Let's generate a script to check the usage of
ibcratelimitin one of the files, for example,rpc.tx.ts. We will look for the import statement and any usage of the namespace within the file.
The output from the script shows that the
ibcratelimitnamespace is being used in therpc.tx.tsfile to create a new instance ofMsgClientImpl. This usage is consistent with the changes made in thebundle.tsfile, where theibcratelimitnamespace was introduced and expanded with new imports.Given this information, it appears that the
ibcratelimitnamespace is being correctly used in at least one of the files where it is referenced. However, to be thorough, we should check the usage in all the files listed in the previous output to ensure consistency across the entire codebase.Since the usage in
rpc.tx.tsis correct, we can proceed to verify the usage in the other files. Let's generate scripts to check the usage ofibcratelimitin the remaining files listed.* 42-67: The changes are part of an effort to update and standardize the codebase. Ensure that these changes align with the project's coding standards and guidelines.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for usage of the new namespace to ensure it's being used correctly. rg 'ibcratelimit' --files-with-matchesLength of output: 603
Script:
#!/bin/bash # Check the usage of `ibcratelimit` in `rpc.tx.ts` rg 'ibcratelimit' "indexer/packages/v4-protos/src/codegen/dydxprotocol/rpc.tx.ts"Length of output: 165
Script:
#!/bin/bash # Check the usage of `ibcratelimit` in the remaining files rg 'ibcratelimit' "indexer/packages/v4-protos/src/codegen/dydxprotocol/rpc.query.ts" rg 'ibcratelimit' "indexer/packages/v4-protos/src/codegen/dydxprotocol/lcd.ts" rg 'ibcratelimit' "indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/tx.rpc.msg.ts" rg 'ibcratelimit' "indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/query.rpc.Query.ts" rg 'ibcratelimit' "indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/query.lcd.ts" rg 'ibcratelimit' "indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/genesis.ts"Length of output: 1403
indexer/packages/v4-protos/src/codegen/dydxprotocol/clob/liquidations.ts (2)
83-88: The removal of
SubaccountOpenPositionInfoandSubaccountOpenPositionInfoSDKTypeinterfaces, along with related functions and constants, is not directly visible in the provided hunks. However, their absence in the final state of the code confirms their removal. Ensure that any code that previously depended on these interfaces or related entities has been updated or refactored to work without them.215-218: > Note: This review was outside the patches, so it was mapped to the patch with the greatest overlap. Original lines [87-218]
The remaining code in the hunks related to
PerpetualLiquidationInfoandSubaccountLiquidationInfointerfaces, along with their respective functions and constants, appears to be correctly structured and consistent with TypeScript best practices. No issues are evident in the provided code.indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/capacity.ts (1)
- 49-50: The use of the non-null assertion operator
!inwriter.uint32(18).bytes(v!)assumes thatvis not null or undefined. IfcapacityListis expected to contain only non-nullableUint8Arrayelements, this is fine. However, if there's a possibility ofnullorundefinedvalues, this could lead to runtime errors. Please ensure thatcapacityListis validated elsewhere in the code to contain only non-nullable elements or handle potential nulls here.indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/genesis.ts (3)
6-14:
The interfacesGenesisStateandGenesisStateSDKTypeare well-defined with clear comments and consistent property naming that aligns with the updated naming conventions.17-20:
ThecreateBaseGenesisStatefunction is correctly implemented to initialize theGenesisStatewith default values.23-60:
Theencode,decode, andfromPartialmethods on theGenesisStateobject are correctly implemented for protobuf serialization and deserialization, including handling of thelimitParamsList.indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/limit_params.ts (1)
- 1-198: The code changes in
limit_params.tsappear to be well-structured and follow the conventions of the protobufjs library. The interfaces and their corresponding SDK types are defined with appropriate property types, and the encoding/decoding functions are implemented correctly. There are no apparent issues with logic, security, performance, or best practices.indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/query.lcd.ts (1)
- 1-38: Verify that the addition of the
LCDQueryClientclass with its methods is intentional and aligns with the PR's objective of upgrading dependency versions. It seems to introduce new functionality rather than just updating dependencies.indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/query.ts (1)
- 1-305: The changes in
query.tsare consistent with the PR's objective to upgrade Cosmos dependencies and align with the updated naming conventions and structural organization. The interfaces and functions are well-documented, and the naming conventions are consistent. The protobuf-relatedencode,decode, andfromPartialfunctions are implemented correctly. There are no apparent performance, security, or PII leakage issues. The code is modular, consistent with the rest of the codebase, and adheres to best practices.indexer/packages/v4-protos/src/codegen/dydxprotocol/ibcratelimit/tx.rpc.msg.ts (1)
- 1-34: The addition of the
Msginterface andMsgClientImplclass for handling RPC message functionality appears to be correctly implemented with proper method bindings and promise-based RPC calls. Ensure that the renaming and reorganization of RPC-related code is consistent across the entire codebase, and that all client code that uses these methods is updated accordingly.indexer/packages/v4-protos/src/codegen/dydxprotocol/rpc.query.ts (2)
19-19: The addition of the
ibcratelimitRPC query client extension appears to be correct and consistent with the structure of the existing code. Ensure that the corresponding module at./ibcratelimit/query.rpc.Queryis present and that thecreateRpcQueryExtensionfunction is correctly implemented to handle the new extension.16-24: If the "ratelimit" extension has been removed as part of the refactoring, please ensure that this change is reflected across all relevant parts of the codebase and that any necessary cleanup or migration of associated data and functionality has been performed.
indexer/packages/v4-protos/src/codegen/dydxprotocol/rpc.tx.ts (1)
- 10-18: The addition of the
ibcratelimitclient and the removal of theratelimitclient in thecreateRPCMsgClientfunction should be verified to ensure that all references to the oldratelimitclient have been updated or removed across the codebase. Additionally, any new functionality or changes associated with theibcratelimitclient should be thoroughly tested to confirm that it integrates correctly with the existing system.
| import { Rpc } from "../../helpers"; | ||
| import * as _m0 from "protobufjs/minimal"; | ||
| import { QueryClient, createProtobufRpcClient } from "@cosmjs/stargate"; | ||
| import { ListLimitParamsRequest, ListLimitParamsResponse, QueryCapacityByDenomRequest, QueryCapacityByDenomResponse } from "./query"; | ||
| /** Query defines the gRPC querier service. */ | ||
|
|
||
| export interface Query { | ||
| /** List all limit params. */ | ||
| listLimitParams(request?: ListLimitParamsRequest): Promise<ListLimitParamsResponse>; | ||
| /** Query capacity by denom. */ | ||
|
|
||
| capacityByDenom(request: QueryCapacityByDenomRequest): Promise<QueryCapacityByDenomResponse>; | ||
| } | ||
| export class QueryClientImpl implements Query { | ||
| private readonly rpc: Rpc; | ||
|
|
||
| constructor(rpc: Rpc) { | ||
| this.rpc = rpc; | ||
| this.listLimitParams = this.listLimitParams.bind(this); | ||
| this.capacityByDenom = this.capacityByDenom.bind(this); | ||
| } | ||
|
|
||
| listLimitParams(request: ListLimitParamsRequest = {}): Promise<ListLimitParamsResponse> { | ||
| const data = ListLimitParamsRequest.encode(request).finish(); | ||
| const promise = this.rpc.request("dydxprotocol.ibcratelimit.Query", "ListLimitParams", data); | ||
| return promise.then(data => ListLimitParamsResponse.decode(new _m0.Reader(data))); | ||
| } | ||
|
|
||
| capacityByDenom(request: QueryCapacityByDenomRequest): Promise<QueryCapacityByDenomResponse> { | ||
| const data = QueryCapacityByDenomRequest.encode(request).finish(); | ||
| const promise = this.rpc.request("dydxprotocol.ibcratelimit.Query", "CapacityByDenom", data); | ||
| return promise.then(data => QueryCapacityByDenomResponse.decode(new _m0.Reader(data))); | ||
| } | ||
|
|
||
| } | ||
| export const createRpcQueryExtension = (base: QueryClient) => { | ||
| const rpc = createProtobufRpcClient(base); | ||
| const queryService = new QueryClientImpl(rpc); | ||
| return { | ||
| listLimitParams(request?: ListLimitParamsRequest): Promise<ListLimitParamsResponse> { | ||
| return queryService.listLimitParams(request); | ||
| }, | ||
|
|
||
| capacityByDenom(request: QueryCapacityByDenomRequest): Promise<QueryCapacityByDenomResponse> { | ||
| return queryService.capacityByDenom(request); | ||
| } | ||
|
|
||
| }; | ||
| }; |
There was a problem hiding this comment.
The implementation of the gRPC client for the ibcratelimit queries appears to be correct and follows TypeScript best practices. The use of string literals for service and method names in rpc.request calls could be replaced with constants for better maintainability. Additionally, consider adding error handling for the gRPC requests if it's not managed elsewhere in the codebase.
| import { LCDClient } from "@osmonauts/lcd"; | ||
| import { ListLimitParamsRequest, ListLimitParamsResponseSDKType, QueryCapacityByDenomRequest, QueryCapacityByDenomResponseSDKType } from "./query"; | ||
| export class LCDQueryClient { | ||
| req: LCDClient; | ||
|
|
||
| constructor({ | ||
| requestClient | ||
| }: { | ||
| requestClient: LCDClient; | ||
| }) { | ||
| this.req = requestClient; | ||
| this.listLimitParams = this.listLimitParams.bind(this); | ||
| this.capacityByDenom = this.capacityByDenom.bind(this); | ||
| } | ||
| /* List all limit params. */ | ||
|
|
||
|
|
||
| async listLimitParams(_params: ListLimitParamsRequest = {}): Promise<ListLimitParamsResponseSDKType> { | ||
| const endpoint = `dydxprotocol/v4/ibcratelimit/list_limit_params`; | ||
| return await this.req.get<ListLimitParamsResponseSDKType>(endpoint); | ||
| } | ||
| /* Query capacity by denom. */ | ||
|
|
||
|
|
||
| async capacityByDenom(params: QueryCapacityByDenomRequest): Promise<QueryCapacityByDenomResponseSDKType> { | ||
| const options: any = { | ||
| params: {} | ||
| }; | ||
|
|
||
| if (typeof params?.denom !== "undefined") { | ||
| options.params.denom = params.denom; | ||
| } | ||
|
|
||
| const endpoint = `dydxprotocol/v4/ibcratelimit/capacity_by_denom`; | ||
| return await this.req.get<QueryCapacityByDenomResponseSDKType>(endpoint, options); | ||
| } | ||
|
|
||
| } |
There was a problem hiding this comment.
The introduction of the LCDQueryClient class with its methods listLimitParams and capacityByDenom is well-structured. The use of async/await is consistent, and the methods are correctly bound to the class instance. However, consider defining a specific type for the options object in capacityByDenom instead of using any to leverage TypeScript's type safety features.
- 26:
- const options: any = {
+ const options: { params: { denom?: 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.
| import { LCDClient } from "@osmonauts/lcd"; | |
| import { ListLimitParamsRequest, ListLimitParamsResponseSDKType, QueryCapacityByDenomRequest, QueryCapacityByDenomResponseSDKType } from "./query"; | |
| export class LCDQueryClient { | |
| req: LCDClient; | |
| constructor({ | |
| requestClient | |
| }: { | |
| requestClient: LCDClient; | |
| }) { | |
| this.req = requestClient; | |
| this.listLimitParams = this.listLimitParams.bind(this); | |
| this.capacityByDenom = this.capacityByDenom.bind(this); | |
| } | |
| /* List all limit params. */ | |
| async listLimitParams(_params: ListLimitParamsRequest = {}): Promise<ListLimitParamsResponseSDKType> { | |
| const endpoint = `dydxprotocol/v4/ibcratelimit/list_limit_params`; | |
| return await this.req.get<ListLimitParamsResponseSDKType>(endpoint); | |
| } | |
| /* Query capacity by denom. */ | |
| async capacityByDenom(params: QueryCapacityByDenomRequest): Promise<QueryCapacityByDenomResponseSDKType> { | |
| const options: any = { | |
| params: {} | |
| }; | |
| if (typeof params?.denom !== "undefined") { | |
| options.params.denom = params.denom; | |
| } | |
| const endpoint = `dydxprotocol/v4/ibcratelimit/capacity_by_denom`; | |
| return await this.req.get<QueryCapacityByDenomResponseSDKType>(endpoint, options); | |
| } | |
| } | |
| import { LCDClient } from "@osmonauts/lcd"; | |
| import { ListLimitParamsRequest, ListLimitParamsResponseSDKType, QueryCapacityByDenomRequest, QueryCapacityByDenomResponseSDKType } from "./query"; | |
| export class LCDQueryClient { | |
| req: LCDClient; | |
| constructor({ | |
| requestClient | |
| }: { | |
| requestClient: LCDClient; | |
| }) { | |
| this.req = requestClient; | |
| this.listLimitParams = this.listLimitParams.bind(this); | |
| this.capacityByDenom = this.capacityByDenom.bind(this); | |
| } | |
| /* List all limit params. */ | |
| async listLimitParams(_params: ListLimitParamsRequest = {}): Promise<ListLimitParamsResponseSDKType> { | |
| const endpoint = `dydxprotocol/v4/ibcratelimit/list_limit_params`; | |
| return await this.req.get<ListLimitParamsResponseSDKType>(endpoint); | |
| } | |
| /* Query capacity by denom. */ | |
| async capacityByDenom(params: QueryCapacityByDenomRequest): Promise<QueryCapacityByDenomResponseSDKType> { | |
| const options: { params: { denom?: string } } = { | |
| params: {} | |
| }; | |
| if (typeof params?.denom !== "undefined") { | |
| options.params.denom = params.denom; | |
| } | |
| const endpoint = `dydxprotocol/v4/ibcratelimit/capacity_by_denom`; | |
| return await this.req.get<QueryCapacityByDenomResponseSDKType>(endpoint, options); | |
| } | |
| } |
| /** MsgDeleteLimitParams is the Msg/SetLimitParams request type. */ | ||
|
|
||
| export interface MsgDeleteLimitParams { | ||
| authority: string; | ||
| /** The denom for which the `LimitParams` should be deleted. */ | ||
|
|
||
| denom: string; | ||
| } | ||
| /** MsgDeleteLimitParams is the Msg/SetLimitParams request type. */ |
There was a problem hiding this comment.
The comment for MsgDeleteLimitParams incorrectly states that it is the request type for Msg/SetLimitParams. This should be corrected to Msg/DeleteLimitParams to accurately reflect the purpose of the message type.
- /** MsgDeleteLimitParams is the Msg/SetLimitParams request type. */
+ /** MsgDeleteLimitParams is the Msg/DeleteLimitParams request type. */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.
| /** MsgDeleteLimitParams is the Msg/SetLimitParams request type. */ | |
| export interface MsgDeleteLimitParams { | |
| authority: string; | |
| /** The denom for which the `LimitParams` should be deleted. */ | |
| denom: string; | |
| } | |
| /** MsgDeleteLimitParams is the Msg/SetLimitParams request type. */ | |
| /** MsgDeleteLimitParams is the Msg/DeleteLimitParams request type. */ | |
| export interface MsgDeleteLimitParams { | |
| authority: string; | |
| /** The denom for which the `LimitParams` should be deleted. */ | |
| denom: string; | |
| } | |
| /** MsgDeleteLimitParams is the Msg/DeleteLimitParams request type. */ |
| export interface MsgDeleteLimitParamsSDKType { | ||
| authority: string; | ||
| /** The denom for which the `LimitParams` should be deleted. */ | ||
|
|
||
| denom: string; | ||
| } | ||
| /** MsgDeleteLimitParamsResponse is the Msg/DeleteLimitParams response type. */ | ||
|
|
||
| export interface MsgDeleteLimitParamsResponse {} |
There was a problem hiding this comment.
Similarly, the comment for MsgDeleteLimitParamsSDKType also incorrectly states that it is the request type for Msg/SetLimitParams. This should be corrected to Msg/DeleteLimitParams.
- /** MsgDeleteLimitParams is the Msg/SetLimitParams request type. */
+ /** MsgDeleteLimitParams is the Msg/DeleteLimitParams request type. */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.
| export interface MsgDeleteLimitParamsSDKType { | |
| authority: string; | |
| /** The denom for which the `LimitParams` should be deleted. */ | |
| denom: string; | |
| } | |
| /** MsgDeleteLimitParamsResponse is the Msg/DeleteLimitParams response type. */ | |
| export interface MsgDeleteLimitParamsResponse {} | |
| export interface MsgDeleteLimitParamsSDKType { | |
| authority: string; | |
| /** The denom for which the `LimitParams` should be deleted. */ | |
| denom: string; | |
| } | |
| /** MsgDeleteLimitParams is the Msg/DeleteLimitParams request type. */ | |
| export interface MsgDeleteLimitParamsResponse {} |
| feetiers: new (await import("./feetiers/query.lcd")).LCDQueryClient({ | ||
| requestClient | ||
| }), | ||
| perpetuals: new (await import("./perpetuals/query.lcd")).LCDQueryClient({ | ||
| ibcratelimit: new (await import("./ibcratelimit/query.lcd")).LCDQueryClient({ | ||
| requestClient | ||
| }), | ||
| prices: new (await import("./prices/query.lcd")).LCDQueryClient({ | ||
| perpetuals: new (await import("./perpetuals/query.lcd")).LCDQueryClient({ | ||
| requestClient | ||
| }), | ||
| ratelimit: new (await import("./ratelimit/query.lcd")).LCDQueryClient({ | ||
| prices: new (await import("./prices/query.lcd")).LCDQueryClient({ | ||
| requestClient | ||
| }), | ||
| rewards: new (await import("./rewards/query.lcd")).LCDQueryClient({ |
There was a problem hiding this comment.
💡 NOTE
Codebase verification is a beta feature.
The changes in the createLCDClient function correctly reflect the renaming of the ratelimit property to ibcratelimit. However, there are still references to ratelimit in the codebase that may need to be reviewed to ensure they are not outdated. No Markdown documentation for createLCDClient was found, which suggests that there might not be any need for updates within this repository's documentation, but external documentation should still be checked.
- Review references to
ratelimitin the codebase to confirm whether they are related to the newibcratelimitmodule or if they are outdated and need updating. - Confirm whether there is external documentation that references
createLCDClientand update it as necessary to reflect the changes made in this pull request.
Analysis chain
The changes in the createLCDClient function correctly reflect the renaming of the ratelimit property to ibcratelimit and the addition of the new imports for ibcratelimit, perpetuals, and prices. Ensure that the rest of the codebase and any documentation are updated to reflect these changes, especially if there are external consumers of this function that rely on the old ratelimit property.
Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that the new property `ibcratelimit` is used correctly throughout the codebase.
rg 'ibcratelimit' --type ts
# Ensure that the old `ratelimit` property is no longer used.
rg 'ratelimit' --type ts
# Check for any documentation that might need updating due to these changes.
rg 'createLCDClient' --type md
Length of output: 7746
Changelist
upgrade Indexer cosmos dependency versions
keep same dependency versions between v4-clients/Indexer for e2e test framework
Test Plan
unit tested
Author/Reviewer Checklist
state-breakinglabel.indexer-postgres-breakinglabel.PrepareProposalorProcessProposal, manually add the labelproposal-breaking.feature:[feature-name].backport/[branch-name].refactor,chore,bug.