Apply updates from core #80
Conversation
Dependency ReviewThe following issues were found:
License Issuespackage-lock.json
package.json
Denied Licenses: GPL-1.0-or-later, LGPL-2.0-or-later OpenSSF Scorecard
Scanned Manifest Filespackage-lock.json
package.json
|
WalkthroughThe changes encompass updates to multiple files, primarily focusing on enhancements to API functionality, message handling, and parameter structures across various modules. Key modifications include the introduction of new methods and classes to facilitate interactions with Ethereum contracts, improvements to inter-blockchain communication (IBC) protocols, and adjustments to message serialization formats. Additionally, several parameters have been renamed or restructured to support new features and improve clarity. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant EvmAPI
participant IbcPermAPI
participant OpchildAPI
participant OphostAPI
User->>EvmAPI: Call erc20Factory()
EvmAPI->>User: Return ERC20 factory address
User->>IbcPermAPI: Call channelStates()
IbcPermAPI->>User: Return channel states
User->>OpchildAPI: Call nextL1Sequence()
OpchildAPI->>User: Return next L1 sequence number
User->>OphostAPI: Call withdrawalClaimed()
OphostAPI->>User: Return withdrawal claim status
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (1)
src/core/ibc/applications/perm/msgs/MsgResumeChannel.ts (1)
6-101: Add parameter validation and unit tests.The
MsgResumeChannelclass follows a consistent pattern for serialization and deserialization, and uses appropriate types and proto definitions. However, there are a few improvements that can be made:
- Add validation for the
authority,channel_id, andport_idparameters in the constructor and deserialization methods (fromAmino,fromData,fromProto).- Add a
validatemethod to validate the parameters.- Add unit tests for the serialization and deserialization methods.
- Add unit tests for the packing and unpacking methods.
- Add unit tests for the validation of parameters.
Here are some suggestions for adding parameter validation and unit tests:
- Add validation for the parameters in the constructor and deserialization methods:
constructor( public authority: AccAddress, public channel_id: string, public port_id: string ) { super() this.validate() } public static fromAmino(data: MsgResumeChannel.Amino): MsgResumeChannel { const { value: { authority, channel_id, port_id }, } = data const msg = new MsgResumeChannel(authority, channel_id, port_id) msg.validate() return msg } public static fromData(data: MsgResumeChannel.Data): MsgResumeChannel { const { authority, channel_id, port_id } = data const msg = new MsgResumeChannel(authority, channel_id, port_id) msg.validate() return msg } public static fromProto(data: MsgResumeChannel.Proto): MsgResumeChannel { const msg = new MsgResumeChannel(data.authority, data.channelId, data.portId) msg.validate() return msg }
- Add a
validatemethod to validate the parameters:public validate(): void { if (!this.authority) { throw new Error('authority is required') } if (!this.channel_id) { throw new Error('channel_id is required') } if (!this.port_id) { throw new Error('port_id is required') } }
- Add unit tests for the serialization and deserialization methods:
describe('MsgResumeChannel', () => { it('should serialize and deserialize to Amino', () => { const msg = new MsgResumeChannel( 'initia1z3t55m0l9h0eupuz3dp5t5cypyv674jj7mz2jw', 'channel-1', 'transfer' ) const amino = msg.toAmino() const msg2 = MsgResumeChannel.fromAmino(amino) expect(msg2).toEqual(msg) }) it('should serialize and deserialize to Data', () => { const msg = new MsgResumeChannel( 'initia1z3t55m0l9h0eupuz3dp5t5cypyv674jj7mz2jw', 'channel-1', 'transfer' ) const data = msg.toData() const msg2 = MsgResumeChannel.fromData(data) expect(msg2).toEqual(msg) }) it('should serialize and deserialize to Proto', () => { const msg = new MsgResumeChannel( 'initia1z3t55m0l9h0eupuz3dp5t5cypyv674jj7mz2jw', 'channel-1', 'transfer' ) const proto = msg.toProto() const msg2 = MsgResumeChannel.fromProto(proto) expect(msg2).toEqual(msg) }) })
- Add unit tests for the packing and unpacking methods:
describe('MsgResumeChannel', () => { it('should pack and unpack Any', () => { const msg = new MsgResumeChannel( 'initia1z3t55m0l9h0eupuz3dp5t5cypyv674jj7mz2jw', 'channel-1', 'transfer' ) const any = msg.packAny() const msg2 = MsgResumeChannel.unpackAny(any) expect(msg2).toEqual(msg) }) })
- Add unit tests for the validation of parameters:
describe('MsgResumeChannel', () => { it('should validate parameters', () => { expect( () => new MsgResumeChannel('', 'channel-1', 'transfer') ).toThrowError('authority is required') expect( () => new MsgResumeChannel('initia1z3t55m0l9h0eupuz3dp5t5cypyv674jj7mz2jw', '', 'transfer') ).toThrowError('channel_id is required') expect( () => new MsgResumeChannel('initia1z3t55m0l9h0eupuz3dp5t5cypyv674jj7mz2jw', 'channel-1', '') ).toThrowError('port_id is required') }) })
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
Files selected for processing (32)
- package.json (2 hunks)
- src/client/lcd/api/EvmAPI.ts (1 hunks)
- src/client/lcd/api/IbcPermAPI.ts (1 hunks)
- src/client/lcd/api/OpchildAPI.ts (1 hunks)
- src/client/lcd/api/OphostAPI.ts (2 hunks)
- src/core/Msg.ts (13 hunks)
- src/core/distribution/msgs/MsgDepositValidatorRewardsPool.ts (2 hunks)
- src/core/evm/EvmParams.ts (2 hunks)
- src/core/evm/msgs/MsgCall.ts (3 hunks)
- src/core/evm/msgs/MsgCreate.ts (2 hunks)
- src/core/evm/msgs/MsgCreate2.ts (1 hunks)
- src/core/evm/msgs/index.ts (1 hunks)
- src/core/gov/GovParams.ts (16 hunks)
- src/core/gov/Vesting.ts (1 hunks)
- src/core/ibc/applications/perm/msgs/MsgHaltChannel.ts (1 hunks)
- src/core/ibc/applications/perm/msgs/MsgResumeChannel.ts (1 hunks)
- src/core/ibc/applications/perm/msgs/MsgSetPermissionedRelayers.ts (5 hunks)
- src/core/ibc/applications/perm/msgs/index.ts (1 hunks)
- src/core/move/MoveParams.ts (10 hunks)
- src/core/opchild/OpchildParams.ts (14 hunks)
- src/core/opchild/msgs/MsgFinalizeTokenDeposit.ts (1 hunks)
- src/core/ophost/BatchInfo.ts (2 hunks)
- src/core/ophost/BatchInfoWithOutput.ts (1 hunks)
- src/core/ophost/BridgeConfig.ts (1 hunks)
- src/core/ophost/Output.ts (3 hunks)
- src/core/ophost/index.ts (1 hunks)
- src/core/ophost/msgs/MsgFinalizeTokenWithdrawal.ts (4 hunks)
- src/core/ophost/msgs/MsgProposeOutput.ts (5 hunks)
- src/core/ophost/msgs/MsgUpdateChallenger.ts (0 hunks)
- src/core/ophost/msgs/MsgUpdateChallengers.ts (1 hunks)
- src/core/ophost/msgs/MsgUpdateOracleConfig.ts (1 hunks)
- src/core/ophost/msgs/index.ts (6 hunks)
Files not reviewed due to no reviewable changes (1)
- src/core/ophost/msgs/MsgUpdateChallenger.ts
Files skipped from review due to trivial changes (4)
- package.json
- src/core/distribution/msgs/MsgDepositValidatorRewardsPool.ts
- src/core/ibc/applications/perm/msgs/MsgSetPermissionedRelayers.ts
- src/core/ophost/msgs/MsgFinalizeTokenWithdrawal.ts
Additional comments not posted (156)
src/core/ophost/index.ts (1)
6-6: LGTM!The export statement for
BatchInfoWithOutputis a straightforward addition that enhances the module's interface without modifying existing logic or control flow. This change is consistent with the PR objective of applying updates from core repositories and is unlikely to have any negative impact on the existing codebase.src/core/evm/msgs/index.ts (5)
7-7: LGTM!The export statement for
MsgCreate2is syntactically correct and consistent with the import statement.
11-11: LGTM!The addition of
MsgCreate2to theEvmMsgunion type is consistent with the import and export statements. It correctly expands the range of supported EVM message types.
14-18: LGTM!The addition of
MsgCreate2.Aminoto theEvmMsg.Aminounion type is consistent with the updatedEvmMsgtype. It correctly includes the Amino encoding for the newMsgCreate2message type.
19-28: LGTM!The additions of
MsgCreate2.DataandMsgCreate2.Prototo theEvmMsg.DataandEvmMsg.Protounion types, respectively, are consistent with the updatedEvmMsgtype. They correctly include the data structure and Protocol Buffers encoding for the newMsgCreate2message type.
2-2: Verify the implementation ofMsgCreate2.The import statement for
MsgCreate2is syntactically correct. However, please ensure that the implementation ofMsgCreate2in the./MsgCreate2file is thoroughly tested and follows the expected behavior.Run the following script to verify the implementation of
MsgCreate2:Verification successful
Implementation of
MsgCreate2VerifiedThe
MsgCreate2class is well-implemented with appropriate properties and methods for serialization and deserialization. It extendsJSONSerializableand includes methods for handling Amino, Proto, and other formats, ensuring compatibility and functionality. No issues were found with the implementation.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of `MsgCreate2`. # Test: Search for the implementation of `MsgCreate2`. Expect: A class or interface named `MsgCreate2` with appropriate properties and methods. fd MsgCreate2 --exec cat | rg --multiline $'(class|interface) MsgCreate2'Length of output: 124
Script:
#!/bin/bash # Description: Gather detailed information about the `MsgCreate2` class. # Search for the full implementation of the `MsgCreate2` class to understand its properties and methods. ast-grep --lang typescript --pattern $'class MsgCreate2 extends $_ { $$$ }'Length of output: 5181
src/core/ibc/applications/perm/msgs/index.ts (4)
2-3: LGTM!The imports of
MsgHaltChannelandMsgResumeChannelare consistent with the AI-generated summary and are necessary for the subsequent changes in the file.
6-7: LGTM!The exports of
MsgHaltChannelandMsgResumeChannelare consistent with the AI-generated summary and are necessary for the subsequent changes in the file and for the consumers of this module.
9-12: LGTM!The update to the
IbcPermMsgtype to includeMsgHaltChannelandMsgResumeChannelis consistent with the AI-generated summary and is necessary for the subsequent changes in the file and for the consumers of this module.
14-25: LGTM!The updates to the
Amino,Data, andProtonamespaces withinIbcPermMsgto includeMsgHaltChannelandMsgResumeChannelare consistent with the AI-generated summary and are necessary for the serialization and deserialization of the new message types.src/client/lcd/api/IbcPermAPI.ts (6)
4-9: LGTM!The renaming of the
PermissionedRelayersinterface toChannelStateand the addition of thehalt_stateproperty are appropriate changes that enhance the representation of channel state information.
11-14: LGTM!The introduction of the
HaltStateinterface is a valuable addition that provides a structured representation of the halted state of a channel. Thehaltedandhalted_byproperties capture the necessary information to determine the channel's operational status and the entity responsible for halting it.
17-25: LGTM!The renaming of the
relayersmethod tochannelStatesaccurately reflects its updated functionality of retrieving channel state information. The changes to the endpoint and return type are consistent with the new data structure and provide the necessary information in the expected format.
28-36: LGTM!The renaming of the
relayersByChannelmethod tochannelStateaccurately reflects its updated functionality of retrieving a specific channel state. The changes to the method parameters, endpoint, and return type are consistent with the new data structure and provide the necessary information in the expected format.
22-24: LGTM!The updated property names in the response object,
channel_statesandpagination, are consistent with the new data structure and naming conventions. Thechannel_statesproperty correctly holds an array ofChannelStateobjects, and thepaginationproperty provides the necessary pagination information.
34-35: LGTM!The updated property name in the response object,
channel_state, is consistent with the new data structure and naming conventions. Thechannel_stateproperty correctly holds a singleChannelStateobject.src/core/ophost/BatchInfo.ts (10)
2-7: LGTM!The new imports are necessary to support the changes made to the
BatchInfoclass. They are correctly named and sourced from the appropriate locations.
17-21: LGTM!The constructor parameter changes improve type safety and clarity:
- Using
AccAddresstype forsubmitterensures that only valid account addresses can be used.- Renaming
chaintochain_typeand using theChainTypeenum provides clarity and type safety for the chain type.
27-28: LGTM!The
fromAminomethod is correctly updated to use the newchain_typeparameter andchainTypeFromJSONfunction for deserialization, ensuring proper handling of thechain_typefield.
32-33: LGTM!The
toAminomethod is correctly updated to use the newchain_typeparameter andchainTypeToJSONfunction for serialization, ensuring proper handling of thechain_typefield.
37-38: LGTM!The
fromDatamethod is correctly updated to use the newchain_typeparameter andchainTypeFromJSONfunction for deserialization, ensuring proper handling of thechain_typefield.
42-43: LGTM!The
toDatamethod is correctly updated to use the newchain_typeparameter andchainTypeToJSONfunction for serialization, ensuring proper handling of thechain_typefield.
47-47: LGTM!The
fromProtomethod is correctly updated to use the newchainTypefield from the proto message, ensuring proper handling of thechain_typefield.
51-54: LGTM!The
toProtomethod is correctly updated to use the newchain_typeparameter when creating the proto message, ensuring proper handling of thechain_typefield.
61-62: LGTM!The
Aminointerface is correctly updated to useAccAddresstype forsubmitterandstringtype forchain_type, aligning with the changes made to the constructor parameters and ensuring type safety.
66-67: LGTM!The
Datainterface is correctly updated to useAccAddresstype forsubmitterandstringtype forchain_type, aligning with the changes made to the constructor parameters and ensuring type safety.src/client/lcd/api/EvmAPI.ts (1)
38-44: LGTM!The new
erc20Factorymethod is a great addition to theEvmAPIclass. It follows the existing coding style and conventions, and its purpose is clearly conveyed through the method name. The implementation is correct, and the optionalparamsparameter provides flexibility for passing additional query parameters if needed.This method enhances the functionality of the
EvmAPIclass by enabling interaction with the ERC20 factory contract, expanding its capabilities in managing Ethereum-based tokens.src/client/lcd/api/OpchildAPI.ts (3)
41-47: LGTM!The
nextL1Sequencemethod is implemented correctly. It fetches the next Layer 1 sequence number from the appropriate API endpoint, expects the response to have anext_l1_sequenceproperty of type string, and correctly parses the string value to an integer usingparseInt. The method signature and return type are accurately defined.
49-55: LGTM!The
nextL2Sequencemethod is implemented correctly. It fetches the next Layer 2 sequence number from the appropriate API endpoint, expects the response to have anext_l2_sequenceproperty of type string, and correctly parses the string value to an integer usingparseInt. The method signature and return type are accurately defined.
57-66: LGTM!The
baseDenommethod is implemented correctly. It fetches the base denomination for a given token from the appropriate API endpoint, expects the response to have abase_denomproperty of type string, and returns the value as a string. The method signature and return type are accurately defined.src/core/evm/msgs/MsgCreate.ts (12)
14-14: LGTM!The JSDoc comment accurately describes the purpose of the new
valueparameter.
18-19: LGTM!The new
valueparameter is correctly added to the constructor.
26-26: LGTM!The destructuring assignment correctly extracts the
valueproperty from thedataobject.
29-29: LGTM!The
valuevariable is correctly passed to theMsgCreateconstructor.
33-33: LGTM!The destructuring assignment correctly extracts the
valueproperty fromthis.
39-39: LGTM!The
valueproperty is correctly added to the returned object.
45-46: LGTM!The destructuring assignment correctly extracts the
valueproperty from thedataobject and passes it to theMsgCreateconstructor.
50-55: LGTM!The destructuring assignment correctly extracts the
valueproperty fromthisand adds it to the returned object.
60-60: LGTM!The
data.valueproperty is correctly passed to theMsgCreateconstructor.
64-68: LGTM!The destructuring assignment correctly extracts the
valueproperty fromthisand adds it to the object passed toMsgCreate_pb.fromPartial.
90-90: LGTM!The
valueproperty is correctly added to theAminointerface.
98-98: LGTM!The
valueproperty is correctly added to theDatainterface.src/core/gov/Vesting.ts (2)
5-66: LGTM!The
Vestingclass is well-structured and follows a consistent pattern for serialization and deserialization. The class properties are clearly defined and match the constructor parameters. The use of TypeScript features like public constructor parameters and type annotations enhances the code readability and maintainability.
68-82: LGTM!The
Vestingnamespace provides a clear separation of the serialization formats. The interfaces are correctly defined and match the properties of theVestingclass, ensuring consistency and type safety.src/core/ophost/BatchInfoWithOutput.ts (5)
1-5: LGTM!The imports are correctly defined and no issues are found.
6-20: LGTM!The class definition and constructor are correctly implemented.
22-71: LGTM!The methods to convert to and from Amino, Data, and Proto formats are correctly implemented.
74-86: LGTM!The namespace and interfaces for Amino, Data, and Proto formats are correctly defined.
1-86: Overall, the code in this file looks great!
- The file follows a consistent structure and naming convention.
- The code is well-documented with JSDoc comments.
- The code follows best practices and is easy to understand.
Great job!
src/core/evm/msgs/MsgCall.ts (5)
15-21: LGTM!The addition of the
valueparameter to theMsgCallconstructor is a valuable enhancement. It allows specifying the amount of tokens to transfer during the contract call, enabling more flexible interactions with the contracts.The code changes are consistent with the provided documentation, clearly explaining the purpose of the new parameter.
28-31: Looks good!The updates to the
fromAminomethod correctly handle the newvaluefield. By destructuring thevaluefield from thedataobject and passing it to theMsgCallconstructor, the method ensures proper deserialization of Amino-encodedMsgCallobjects.These changes maintain consistency with the modifications made to the constructor.
35-42: Looks good!The updates to the
toAminomethod correctly include the newvaluefield. By destructuring thevaluefield from the current instance and including it in the returned Amino-encoded object, the method ensures proper serialization ofMsgCallobjects to Amino format.These changes maintain consistency with the modifications made to the constructor.
48-49: Looks good!The updates to the
fromDatamethod correctly handle the newvaluefield. By destructuring thevaluefield from thedataobject and passing it to theMsgCallconstructor, the method ensures proper deserialization of JSON-serializedMsgCallobjects.These changes maintain consistency with the modifications made to the constructor.
53-59: Looks good!The updates to the
toDatamethod correctly include the newvaluefield. By destructuring thevaluefield from the current instance and including it in the returned JSON-serialized object, the method ensures proper serialization ofMsgCallobjects to JSON format.These changes maintain consistency with the modifications made to the constructor.
src/core/ophost/msgs/index.ts (5)
8-8: LGTM!The import statement has been correctly renamed to
MsgUpdateChallengers, which aligns with the AI-generated summary indicating support for multiple challengers. This change is consistent and enhances the functionality.
10-10: LGTM!The new import statement for
MsgUpdateOracleConfighas been correctly added, which aligns with the AI-generated summary indicating the introduction of new configuration options for oracles. This change enhances the system's capabilities.
21-21: LGTM!The export statements for
MsgUpdateChallengersandMsgUpdateOracleConfighave been correctly added, which is consistent with the new import statements. These changes correctly expose the new message types for usage in other parts of the codebase.Also applies to: 23-23
35-35: LGTM!The
OphostMsgtype and its associated type unions (Amino,Data,Proto) have been correctly updated to includeMsgUpdateChallengersandMsgUpdateOracleConfig. These changes are consistent with the new import and export statements, ensuring that the new message types are properly recognized throughout the messaging system.Also applies to: 37-37, 50-50, 52-52, 64-64, 66-66, 78-78, 80-80
Line range hint
1-84: Overall, the changes in this file look great!The modifications to support multiple challengers and introduce new configuration options for oracles are consistently applied across import statements, export statements, and type definitions. The changes enhance the functionality and capabilities of the Ophost messaging system, and the AI-generated summary accurately captures the essence of the updates.
No issues, inconsistencies, or areas for improvement are identified. The changes are well-structured and align with the project's objectives.
src/core/ibc/applications/perm/msgs/MsgHaltChannel.ts (7)
1-10: LGTM!The imports and class definition are correctly specified and follow the expected patterns for the
@initia/initia.jspackage.
11-29: LGTM!The constructor and the
fromAminostatic method are correctly implemented and follow the expected patterns for the@initia/initia.jspackage.
31-41: LGTM!The
toAminomethod is correctly implemented and follows the expected pattern for the@initia/initia.jspackage.
43-56: LGTM!The
fromDatastatic method and thetoDatamethod are correctly implemented and follow the expected patterns for the@initia/initia.jspackage.
58-69: LGTM!The
fromProtostatic method and thetoProtomethod are correctly implemented and follow the expected patterns for the@initia/initia.jspackage. The methods correctly handle the conversion between theMsgHaltChannelclass and its protocol buffer representation.
71-80: LGTM!The
packAnymethod and theunpackAnystatic method are correctly implemented and follow the expected patterns for the@initia/initia.jspackage. The methods correctly handle the conversion between theMsgHaltChannelclass and its packedAnyrepresentation.
83-101: LGTM!The interface definitions for
Amino,Data, andProtoare correctly specified and match the expected structures for the different encodings of theMsgHaltChannelmessage.src/core/ophost/Output.ts (14)
12-12: LGTM!The JSDoc comment accurately describes the new
l1_block_numberparameter.
18-18: LGTM!The new
l1_block_numberproperty is correctly typed and aligns with the changes made to the constructor.
26-27: LGTM!The destructuring of the new
l1_block_numberproperty in thefromAminomethod is correctly implemented and aligns with the changes made to theAminointerface.
30-30: LGTM!The parsing and passing of the
l1_block_numberproperty in thefromAminomethod are correctly implemented.
37-38: LGTM!The destructuring of the new
l1_block_numberproperty in thetoAminomethod is correctly implemented and aligns with the changes made to theOutputclass.
41-41: LGTM!The inclusion and conversion of the
l1_block_numberproperty in the returnedAminoobject are correctly implemented and align with theAminointerface.
48-49: LGTM!The destructuring of the new
l1_block_numberproperty in thefromDatamethod is correctly implemented and aligns with the changes made to theDatainterface.
52-52: LGTM!The parsing and passing of the
l1_block_numberproperty in thefromDatamethod are correctly implemented.
59-60: LGTM!The destructuring of the new
l1_block_numberproperty in thetoDatamethod is correctly implemented and aligns with the changes made to theOutputclass.
63-63: LGTM!The inclusion and conversion of the
l1_block_numberproperty in the returnedDataobject are correctly implemented and align with theDatainterface.
72-73: LGTM!The passing and conversion of the
l1BlockNumberproperty in thefromProtomethod are correctly implemented and align with thePrototype.
79-80: LGTM!The destructuring, inclusion, and conversion of the
l1_block_numberproperty in thetoProtomethod are correctly implemented and align with thePrototype.Also applies to: 83-83
93-93: LGTM!The addition of the
l1_block_numberproperty to theAminointerface is correctly implemented and aligns with the changes made to thefromAminoandtoAminomethods.
100-100: LGTM!The addition of the
l1_block_numberproperty to theDatainterface is correctly implemented and aligns with the changes made to thefromDataandtoDatamethods.src/core/ibc/applications/perm/msgs/MsgResumeChannel.ts (1)
1-5: LGTM!The imports are correctly specified, sorted, grouped, and aliased.
src/core/evm/msgs/MsgCreate2.ts (8)
7-93: LGTM!The
MsgCreate2class is correctly implemented with appropriate serialization and deserialization methods for Amino, Data, and Proto formats. The constructor parameters are correctly typed and documented.
27-33: LGTM!The
fromAminomethod is correctly implemented and handles the conversion ofsaltfrom string to number usingNumber.parseInt.
35-46: LGTM!The
toAminomethod is correctly implemented and handles the conversion ofsaltfrom number to string usingtoString.
48-51: LGTM!The
fromDatamethod is correctly implemented and handles the conversion ofsaltfrom string to number usingNumber.parseInt.
53-62: LGTM!The
toDatamethod is correctly implemented and handles the conversion ofsaltfrom number to string usingtoString.
64-71: LGTM!The
fromProtomethod is correctly implemented and handles the conversion ofsaltfromLongto number usingtoNumber.
73-81: LGTM!The
toProtomethod is correctly implemented and handles the conversion ofsaltfrom number toLongusingLong.fromNumber.
83-92: LGTM!The
packAnyandunpackAnymethods are correctly implemented and handle the packing and unpacking ofMsgCreate2instances to/fromAnyobjects.src/core/ophost/msgs/MsgUpdateOracleConfig.ts (2)
7-103: LGTM!The
MsgUpdateOracleConfigclass is correctly implemented:
- It extends
JSONSerializableand implements the required methods for serialization and deserialization to/from Amino, Data, and Proto formats.- The constructor parameters are correctly typed and match the fields in the Amino, Data, and Proto interfaces.
- The serialization and deserialization methods are correctly implemented and handle the type conversions appropriately.
105-123: LGTM!The
MsgUpdateOracleConfignamespace is correctly defined:
- It defines interfaces for Amino, Data, and Proto formats.
- The interfaces correctly match the fields in the
MsgUpdateOracleConfigclass.src/core/ophost/msgs/MsgUpdateChallengers.ts (7)
17-23: LGTM!The constructor is correctly assigning the parameters to the class properties and calling the
super()method.
25-37: LGTM!The
fromAminomethod is correctly extracting the values from theAminoobject and returning a new instance ofMsgUpdateChallengers.
39-49: LGTM!The
toAminomethod is correctly returning anAminoobject with the class properties.
51-60: LGTM!The
fromDatamethod is correctly extracting the values from theDataobject and returning a new instance ofMsgUpdateChallengers.
62-70: LGTM!The
toDatamethod is correctly returning aDataobject with the class properties.
72-89: LGTM!The
fromProtoandtoProtomethods are correctly converting betweenProtoandMsgUpdateChallengersinstances. Thebridge_idis also correctly converted betweenLongand number.
91-102: LGTM!The
packAnyandunpackAnymethods are correctly packing and unpacking theMsgUpdateChallengersinstance as anAnyproto. ThetypeUrlis correctly set to the fully qualified name of the message type, and thevalueis correctly encoded and decoded using theMsgUpdateChallengers_pbmethods.src/core/move/MoveParams.ts (6)
19-19: LGTM!The constructor has been correctly updated to include the new
script_enabledparameter.
31-31: LGTM!The
fromAminomethod has been correctly updated to handle the deserialization of the newscript_enabledproperty from the Amino format.Also applies to: 39-39
49-49: LGTM!The
toAminomethod has been correctly updated to include thescript_enabledproperty in the serialized Amino object.Also applies to: 58-58
69-69: LGTM!The
fromDatamethod has been correctly updated to handle the deserialization of the newscript_enabledproperty from the Data format.Also applies to: 76-76
86-86: LGTM!The
toDatamethod has been correctly updated to include thescript_enabledproperty in the serialized Data object.Also applies to: 94-94
104-104: LGTM!The
fromProtoandtoProtomethods have been correctly updated to handle the serialization and deserialization of the newscript_enabledproperty to and from the Proto format.The
AminoandDatainterfaces have been correctly updated to include the newscript_enabledproperty, ensuring that the structure of the serialized objects is consistent with the class definition.Also applies to: 114-114, 121-121, 134-134, 144-144
src/core/evm/EvmParams.ts (9)
12-21: LGTM!The addition of the new constructor parameters
allow_custom_erc20,allowed_custom_erc20s, andfee_denomenhances the flexibility of theEvmParamsclass. The parameter names are descriptive, and the JSDoc comments provide clear explanations of their purpose.
27-40: LGTM!The updates to the
fromAminomethod correctly handle the deserialization of the new parametersallow_custom_erc20,allowed_custom_erc20s, andfee_denomfrom the Amino format. The destructuring assignment and theEvmParamsconstructor call are updated consistently to include the new parameters.
44-56: LGTM!The updates to the
toAminomethod correctly handle the serialization of the new parametersallow_custom_erc20,allowed_custom_erc20s, andfee_denomto the Amino format. The destructuring assignment and the returned object are updated consistently to include the new parameters.
61-74: LGTM!The updates to the
fromDatamethod correctly handle the deserialization of the new parametersallow_custom_erc20,allowed_custom_erc20s, andfee_denomfrom the Data format. The destructuring assignment and theEvmParamsconstructor call are updated consistently to include the new parameters.
78-90: LGTM!The updates to the
toDatamethod correctly handle the serialization of the new parametersallow_custom_erc20,allowed_custom_erc20s, andfee_denomto the Data format. The destructuring assignment and the returned object are updated consistently to include the new parameters.
97-100: LGTM!The updates to the
fromProtomethod correctly handle the deserialization of the new parametersallowCustomErc20,allowedCustomErc20s, andfeeDenomfrom the Proto format. TheEvmParamsconstructor call is updated to pass the new parameters from the proto object.
105-117: LGTM!The updates to the
toProtomethod correctly handle the serialization of the new parametersallow_custom_erc20,allowed_custom_erc20s, andfee_denomto the Proto format. The destructuring assignment and theParams_pb.fromPartialcall are updated consistently to include the new parameters.
126-128: LGTM!The updates to the
Aminointerface correctly include the new propertiesallow_custom_erc20,allowed_custom_erc20s, andfee_denom, matching the new parameters added to theEvmParamsclass.
134-136: LGTM!The updates to the
Datainterface correctly include the new propertiesallow_custom_erc20,allowed_custom_erc20s, andfee_denom, matching the new parameters added to theEvmParamsclass.src/core/ophost/msgs/MsgProposeOutput.ts (10)
15-15: LGTM!The JSDoc comment has been updated to include the new
output_indexparameter, which is consistent with the changes made to the constructor.
22-22: LGTM!The new
output_indexparameter has been added to the constructor, and it is used consistently throughout the class in various methods such asfromAmino,toAmino,fromData,toData, andtoProto.
31-37: LGTM!The
fromAminomethod has been updated to include theoutput_indexparameter, and it is correctly parsed as an integer usingNumber.parseInt. These changes are consistent with the addition ofoutput_indexto the constructor.Also applies to: 42-42
49-50: LGTM!The
toAminomethod has been updated to include theoutput_indexparameter, and it is correctly converted to a string using thetoStringmethod. These changes are consistent with the addition ofoutput_indexto the constructor and ensure proper serialization in the Amino format.Also applies to: 56-56
64-65: LGTM!The
fromDatamethod has been updated to include theoutput_indexparameter, and it is correctly parsed as an integer usingNumber.parseInt. These changes are consistent with the addition ofoutput_indexto the constructor.Also applies to: 69-69
76-77: LGTM!The
toDatamethod has been updated to include theoutput_indexparameter, and it is correctly converted to a string using thetoStringmethod. These changes are consistent with the addition ofoutput_indexto the constructor and ensure proper serialization in the Data format.Also applies to: 82-82
92-92: LGTM!The
fromProtomethod has been updated to include theoutputIndexparameter, and it is correctly converted from aLongtype to a number using thetoNumbermethod. This change is consistent with the addition ofoutput_indexto the constructor and ensures proper deserialization from the Proto format.
99-100: LGTM!The
toProtomethod has been updated to include theoutput_indexparameter, and it is correctly converted to aLongtype using theLong.fromNumbermethod. These changes are consistent with the addition ofoutput_indexto the constructor and ensure proper serialization in the Proto format.Also applies to: 104-104
128-128: LGTM!The
Aminointerface has been updated to include theoutput_indexproperty of typestring, which is consistent with the addition ofoutput_indexto the constructor and its usage in thetoAminomethod. This change ensures type safety and matches the serialization format.
138-138: LGTM!The
Datainterface has been updated to include theoutput_indexproperty of typestring, which is consistent with the addition ofoutput_indexto the constructor and its usage in thetoDatamethod. This change ensures type safety and matches the serialization format.src/core/opchild/OpchildParams.ts (6)
17-17: LGTM!The documentation comment accurately reflects the change from a single bridge executor to an array of bridge executors.
25-25: LGTM!The constructor parameter change from
bridge_executortobridge_executorsis consistent with the overall modifications to support multiple bridge executors.
39-39: LGTM!The
bridge_executorparameter has been consistently renamed tobridge_executorsin all the serialization and deserialization methods.Also applies to: 49-49, 60-60, 71-71, 83-83, 92-92, 103-103, 113-113
124-124: LGTM!The
bridge_executorparameter has been consistently renamed tobridge_executorsin thefromProtoandtoProtomethods that convert between theOpchildParamsobject and the protobuf representation.Also applies to: 135-135, 144-144
158-158: LGTM!The
bridge_executorfield has been consistently renamed tobridge_executorsin theAminointerface that represents the amino encoding of theOpchildParamsobject.
169-169: LGTM!The
bridge_executorfield has been consistently renamed tobridge_executorsin theDatainterface that represents the JSON encoding of theOpchildParamsobject.src/core/opchild/msgs/MsgFinalizeTokenDeposit.ts (2)
Line range hint
21-31: LGTM!The addition of the
base_denomparameter to the constructor is a valid change. It provides more information about the token being deposited, which can be useful for handling multiple token types or currencies. The parameter is correctly typed and the JSDoc comment has been updated to include its description.
Line range hint
39-134: LGTM!The methods
fromAmino,toAmino,fromData,toData,fromProto, andtoProtohave been updated to handle the newbase_denomparameter correctly. The parameter is passed to the constructor when creating a new instance ofMsgFinalizeTokenDepositin thefrom*methods, and thebase_denomfield is included in the returned objects in theto*methods. The changes are consistent and do not introduce any type mismatches or inconsistencies.Additionally, the
AminoandDatainterfaces in theMsgFinalizeTokenDepositnamespace have been updated to include thebase_denomfield, which is in line with the changes made to the class.src/client/lcd/api/OphostAPI.ts (3)
143-156: LGTM!The
withdrawalClaimedmethod is implemented correctly. It follows the expected logic, has a clear naming convention, and properly handles the request and response.
158-167: LGTM!The
nextL1Sequencemethod is implemented correctly. It follows the expected logic, has a clear naming convention, and properly handles the request and response.
169-182: LGTM!The
batchInfosmethod is implemented correctly. It follows the expected logic, has a clear naming convention, and properly handles the request and response. The method appropriately utilizes theBatchInfoWithOutput.fromDatamethod to convert the raw data into instances of theBatchInfoWithOutputclass.src/core/ophost/BridgeConfig.ts (10)
6-6: LGTM!The import statement for the
Longlibrary is correct and necessary for using theLongtype in the code.
14-20: LGTM!The JSDoc comments have been updated to accurately reflect the changes made to the constructor parameters:
challengersis now an array of addresses.submission_start_timeis renamed tosubmission_start_height.- A new parameter
oracle_enabledis added.
24-30: LGTM!The constructor parameters have been updated to match the changes in the JSDoc comments:
challengeris replaced withchallengers, which is an array of addresses.submission_start_timeis renamed tosubmission_start_height.- A new parameter
oracle_enabledis added.
38-55: LGTM!The
fromAminomethod has been updated to match the changes in the constructor parameters:
challengeris replaced withchallengers.submission_start_timeis renamed tosubmission_start_height.- A new property
oracle_enabledis added.
62-79: LGTM!The
toAminomethod has been updated to match the changes in the constructor parameters:
challengeris replaced withchallengers.submission_start_timeis renamed tosubmission_start_height.- A new property
oracle_enabledis added.
86-103: LGTM!The
fromDatamethod has been updated to match the changes in the constructor parameters:
challengeris replaced withchallengers.submission_start_timeis renamed tosubmission_start_height.- A new property
oracle_enabledis added.
110-127: LGTM!The
toDatamethod has been updated to match the changes in the constructor parameters:
challengeris replaced withchallengers.submission_start_timeis renamed tosubmission_start_height.- A new property
oracle_enabledis added.
134-140: LGTM!The
fromProtomethod has been updated to match the changes in the constructor parameters:
challengeris replaced withchallengers.submission_start_timeis renamed tosubmission_start_height.- A new property
oracle_enabledis added.
147-164: LGTM!The
toProtomethod has been updated to match the changes in the constructor parameters:
challengeris replaced withchallengers.submission_start_timeis renamed tosubmission_start_height.- A new property
oracle_enabledis added.
172-189: LGTM!The
AminoandDatainterfaces have been updated to match the changes in the constructor parameters:
challengeris replaced withchallengers.submission_start_timeis renamed tosubmission_start_height.- A new property
oracle_enabledis added.src/core/gov/GovParams.ts (6)
5-5: LGTM!The import statement is necessary to use the
Vestingtype in theGovParamsclass.
37-37: LGTM!The new optional
vestingparameter is properly typed and documented. It is used to hold information about the vesting contract related to the tally process in governance proposals.
58-59: LGTM!
- The new
low_threshold_functionsparameter is properly typed and documented. It is used to specify the low threshold functions for emergency and expedited proposals.- The new optional
vestingproperty is properly typed and matches the new optional constructor parameter.
88-88: LGTM!The changes to the
fromAminomethod ensure that thevestinginformation is properly deserialized from Amino format, maintaining compatibility with existing functionality while extending the class's capabilities to handle vesting-related data.Also applies to: 110-111
136-136: LGTM!The changes to the
toAminomethod ensure that thevestinginformation is properly serialized to Amino format, maintaining compatibility with existing functionality while extending the class's capabilities to handle vesting-related data.Also applies to: 159-159
184-184: LGTM!The changes to the
fromData,toData,fromProto, andtoProtomethods, as well as theAminoandDatainterfaces in theGovParamsnamespace, ensure that thevestinginformation is properly serialized and deserialized to and from Data and Proto formats, maintaining compatibility with existing functionality while extending the class's capabilities to handle vesting-related data.Also applies to: 206-207, 232-232, 255-255, 279-280, 305-305, 328-328, 354-354, 377-377
src/core/Msg.ts (6)
31-37: LGTM!The imports are correctly added.
86-91: LGTM!The imports are correctly added.
426-428: LGTM!The case statement is correctly added to handle
MsgDepositValidatorRewardsPoolin thefromAminomethod.
436-437: LGTM!The case statement is correctly added to handle
MsgCreate2in thefromAminomethod.
520-523: LGTM!The case statements are correctly added to handle
MsgHaltChannelandMsgResumeChannelin thefromAminomethod.
624-629: Verify the usage ofMsgUpdateChallengersandMsgUpdateOracleConfig.The changes look good:
- The case statement for
MsgUpdateChallengeris correctly renamed toMsgUpdateChallengers.- The new case statement for
MsgUpdateOracleConfigis correctly added.Run the following script to verify the usage of
MsgUpdateChallengersandMsgUpdateOracleConfig:Verification successful
Verification Successful: Usage of
MsgUpdateChallengersandMsgUpdateOracleConfigConfirmedThe usage of
MsgUpdateChallengersandMsgUpdateOracleConfigis correctly implemented throughout the codebase. The oldMsgUpdateChallengeris no longer present, confirming the successful transition.
MsgUpdateChallengersis used in multiple locations, includingsrc/core/Msg.tsandsrc/core/ophost/msgs/index.ts.MsgUpdateOracleConfigis also used in several places, such assrc/core/Msg.tsandsrc/core/ophost/msgs/index.ts.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: # - Verify the usage of `MsgUpdateChallengers` and `MsgUpdateOracleConfig`. # - Expect: The messages are used correctly and the old `MsgUpdateChallenger` is not used anymore. # Test: Search for the usage of `MsgUpdateChallengers`. Expect: Should find occurrences. echo "Verifying usage of MsgUpdateChallengers:" rg --type typescript -A 5 $'MsgUpdateChallengers' # Test: Search for the usage of `MsgUpdateOracleConfig`. Expect: Should find occurrences. echo "Verifying usage of MsgUpdateOracleConfig:" rg --type typescript -A 5 $'MsgUpdateOracleConfig' # Test: Search for the usage of the old `MsgUpdateChallenger`. Expect: Should not find occurrences. echo "Verifying the old MsgUpdateChallenger is not used anymore:" rg --type typescript -A 5 $'MsgUpdateChallenger'Length of output: 562
Script:
#!/bin/bash # Description: # - Verify the usage of `MsgUpdateChallengers` and `MsgUpdateOracleConfig`. # - Expect: The messages are used correctly and the old `MsgUpdateChallenger` is not used anymore. # Test: Search for the usage of `MsgUpdateChallengers`. Expect: Should find occurrences. echo "Verifying usage of MsgUpdateChallengers:" rg --glob '*.ts' -A 5 $'MsgUpdateChallengers' # Test: Search for the usage of `MsgUpdateOracleConfig`. Expect: Should find occurrences. echo "Verifying usage of MsgUpdateOracleConfig:" rg --glob '*.ts' -A 5 $'MsgUpdateOracleConfig' # Test: Search for the usage of the old `MsgUpdateChallenger`. Expect: Should not find occurrences. echo "Verifying the old MsgUpdateChallenger is not used anymore:" rg --glob '*.ts' -A 5 $'MsgUpdateChallenger'Length of output: 32693
Summary by CodeRabbit
New Features
MsgHaltChannel,MsgResumeChannel, andMsgUpdateChallengers.EvmParamsto include custom ERC20 token management and transaction fee specifications.MsgUpdateOracleConfig.Bug Fixes
Documentation