chores: bump deps and update swagger #92
Conversation
WalkthroughThis pull request updates the Go version across multiple configurations by upgrading from 1.22 to 1.23. Changes affect GitHub Actions workflows, Dockerfiles, go.mod, and README prerequisites. Additionally, several application components have been refactored, including updates to parameter lists in handler initializations in the SDK, modifications to IBC hook test types, and adjustments to forwarding package imports. Documentation is enhanced in the swagger file with new endpoints and response clarifications. Changes
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
⏰ Context from checks skipped due to timeout of 90000ms (1)
🪧 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: 1
🔭 Outside diff range comments (1)
app/ibc-hooks/util.go (1)
42-42: Remove unused constant.The
wasmPortPrefixconstant is no longer used after the packet data decoding simplification.Apply this diff to remove the unused constant:
-const wasmPortPrefix = "wasm."🧰 Tools
🪛 GitHub Actions: Lint
[warning] 42-42: const
wasmPortPrefixis unused
🧹 Nitpick comments (11)
client/docs/swagger-ui/swagger.yaml (10)
22332-22344: Consistent RevisionHeight Documentation
The added explanatory text reiterates that theRevisionHeightgets reset and that the JSON marshaller always emits a value—even if zero—because theomitemptyflag is excluded. The explanation is consistent with other sections; consider a common reference if similar blocks repeat.
23514-23526: Clarification on RevisionHeight Reset in QuerySequenceResponse
The added note makes it explicit how theRevisionHeightfield is treated. It’s informative and consistent with similar endpoints. Consider reviewing all instances to check if a consolidated explanation would be more maintainable.
26279-26291: RevisionHeight Update in QueryUpgradeResponse Documentation
The added documentation clarifies how theRevisionHeightfield behaves. Since similar blocks appear elsewhere, consider a unified explanation to avoid verbosity.
65419-65431: Reiteration of RevisionHeight Documentation with Timestamp
The updated text aboutRevisionHeight(plus timestamp formatting) is consistent with earlier changes. Although clear, this repetition across the file suggests that consolidating common documentation might be beneficial.
65871-65883: Consistent RevisionHeight Behavior Documentation
The hunk reiterates the same explanatory text aboutRevisionHeightand the JSON omitting behavior. While correct, consider condensing repeated text into a shared reference for maintainability.
66224-66236: RevisionHeight Documentation for QueryChannelsResponse
This hunk revisits the common note regardingRevisionHeight. The explanation is clear; consider reducing verbosity by centralizing common documentation remarks across endpoints.
67126-67138: RevisionHeight Documentation Update for QueryUpgradeResponse
This block restates the standard behavior forRevisionHeight. While clear, the information is repetitive; you might consider using a shared note to improve maintainability.
67272-67284: Reiterated RevisionHeight and Timestamp Note
This hunk repeats the standard explanation regardingRevisionHeightand timestamps. Although correct, consolidating similar notes could help reduce duplication.
68521-68533: RevisionHeight Documentation in Height Data Type
This hunk maintains the standard explanation for theRevisionHeightfield. While the text is clear, consider reducing repeated language by referencing a common description block.
68577-68589: Reiterated RevisionHeight Explanatory Text
The note about the JSON tag behavior forRevisionHeightis consistently applied here. To improve maintainability, you might consider centralizing these recurring details..github/workflows/build-darwin-amd64.yml (1)
50-50: Typographical Error in Build Step NameThe step name at line 50 is written as "Build and Package for Darwin ADM642". This appears to be a typographical error and should likely read "Build and Package for Darwin AMD64" to match the file name and architecture identifier.
For example, you may apply the following diff:
- - name: Build and Package for Darwin ADM642 + - name: Build and Package for Darwin AMD64
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (19)
.github/workflows/build-darwin-amd64.yml(1 hunks).github/workflows/build-darwin-arm64.yml(1 hunks).github/workflows/build-linux-amd64.yml(1 hunks).github/workflows/test.yml(1 hunks)Dockerfile(1 hunks)Dockerfile.arm64(1 hunks)README.md(1 hunks)app/blocksdk.go(1 hunks)app/ibc-hooks/ack_test.go(2 hunks)app/ibc-hooks/receive_test.go(2 hunks)app/ibc-hooks/timeout_test.go(2 hunks)app/ibc-hooks/util.go(1 hunks)app/ibc-hooks/util_test.go(1 hunks)app/keepers/keepers.go(2 hunks)app/keepers/keys.go(1 hunks)app/modules.go(1 hunks)client/docs/swagger-ui/swagger.yaml(81 hunks)go.mod(11 hunks)shared.Dockerfile(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- shared.Dockerfile
- app/modules.go
🧰 Additional context used
🪛 GitHub Actions: Lint
app/ibc-hooks/util.go
[warning] 42-42: const wasmPortPrefix is unused
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Run test and upload codecov
- GitHub Check: Analyze (go)
🔇 Additional comments (101)
app/keepers/keys.go (1)
46-46: LGTM! Import path simplified.The change to a flatter import path structure is a good improvement that aligns with modern Go module practices.
app/keepers/keepers.go (2)
99-101: LGTM! Import paths simplified.The changes to flatter import paths align with modern Go module practices and the PR's dependency update objectives.
320-322: LGTM! Method name updated.The change from
WithPostUpdateHandlertoSetPostUpdateHandlerappears to be part of the dependency updates mentioned in the PR objectives.app/ibc-hooks/util_test.go (1)
38-38: LGTM!The change correctly aligns with the removal of
wasmPortPrefixfrom the packet data decoding logic.app/blocksdk.go (2)
132-138: LGTM!The parameter reordering and addition of
app.BaseAppalign with the updated block-sdk v2 API.
141-147: LGTM!The change from
NewProposalHandlertoNewwith the additional boolean parameter reflects the updated block-sdk v2 API.app/ibc-hooks/util.go (1)
49-49: LGTM!The simplified packet data decoding logic correctly removes the unnecessary port prefix handling.
app/ibc-hooks/timeout_test.go (1)
116-116: LGTM!The type update from
NonFungibleTokenPacketDataWasmtoNonFungibleTokenPacketDatacorrectly aligns with the dependency updates.Also applies to: 165-165
app/ibc-hooks/receive_test.go (2)
132-142: LGTM! Type update aligns with dependency changes.The change from
NonFungibleTokenPacketDataWasmtoNonFungibleTokenPacketDatais consistent with the dependency updates in the PR.
179-196: LGTM! Type update maintains test consistency.The type change is applied consistently across test functions while preserving the test logic and data structure.
app/ibc-hooks/ack_test.go (2)
135-145: LGTM! Type update is consistent.The change from
NonFungibleTokenPacketDataWasmtoNonFungibleTokenPacketDatais applied consistently with other test files.
187-201: LGTM! Type update preserves test behavior.The type change maintains the same structure and test behavior while aligning with the dependency updates.
client/docs/swagger-ui/swagger.yaml (70)
21938-21950: Clarify RevisionHeight Reset Behavior
This hunk adds detailed documentation for theRevisionHeightfield, emphasizing that the JSON marshaller will always emit zero values for bothrevision_numberandrevision_heightby explicitly omitting theomitemptytag. The explanation is clear; however, since similar language is repeated in later sections, you might consider centralizing this explanation in a common note to reduce redundancy.
22794-22806: RevisionHeight Explanation for QueryChannelClientStateResponse
This change adds clarification regarding theRevisionHeightbehavior for the response type of theQueryChannelClientStateResponseRPC. The detailed note improves clarity for API consumers.
23236-23248: RevisionHeight Documentation in QueryChannelClientStateResponse
The documentation update explains that the JSON tags for generated Go code are overridden to excludeomitempty, ensuring zero values are always emitted. The update is clear and consistent.
23778-23790: Detailed RevisionHeight Behavior in QueryNextSequenceSendResponse
The update clearly documents that the generated JSON output will always include a value forRevisionHeightdespite resets. This detail improves precision in the API documentation.
24425-24437: RevisionHeight Documentation in QueryPacketAcknowledgementResponse
The updated text clearly explains that the JSON marshaller will emit zero values forrevision_numberandrevision_heightdue to the excludedomitemptytag. The documentation is consistent with previous updates.
24751-24763: RevisionHeight Note for QueryPacketCommitmentsResponse
The documentation here emphasizes the override of theomitemptytag for theRevisionHeightfield, ensuring that a zero value is always output. The message is clear and consistent.
25073-25085: Consistent RevisionHeight Update in QueryUnreceivedAcksResponse
The hunk reinforces the behavior of theRevisionHeightfield, stating that the JSON marshaller does not omit the field—even when zero. This consistency benefits API consumers, although the repeated text might be consolidated in a common reference.
25349-25361: RevisionHeight Note for QueryUnreceivedPacketsResponse
The added explanation is consistent with similar sections and documents thatRevisionHeightis always present in the response.
25623-25635: RevisionHeight Documentation in QueryPacketCommitmentResponse
This update clearly documents the behavior of theRevisionHeightfield. The note is helpful and consistent with the pattern used throughout the file.
25901-25913: RevisionHeight Explanation in QueryPacketReceiptResponse
The documentation effectively clarifies that the JSON marshaller always emits a value for theRevisionHeightfield, reinforcing consistency in API responses.
26204-26218: Extended RevisionHeight Note with Timestamp Information
This hunk includes mention of timestamp formatting along with theRevisionHeightexplanation. It is detailed and useful; ensure that the timestamp type (“string” with formatuint64) is correct per your backend specification.
26555-26567: RevisionHeight Note for QueryUpgradeErrorResponse
This change documents the behavior ofRevisionHeightin error responses clearly. The text is consistent with previous notes.
26934-26946: RevisionHeight Clarification for QueryConnectionChannelsResponse
The updated text ensures that the behavior of theRevisionHeightfield is well explained in the context of connection channels.
27250-27264: RevisionHeight and Timestamp Documentation for QueryClientStateResponse
This block reinforces the details on theRevisionHeightfield and its treatment alongside timestamp information. The explanation is correct and detailed.
28187-28199: RevisionHeight Explanation in QueryClientStateResponse
The update clearly documents the treatment ofRevisionHeight, ensuring that even when reset, its zero value is always emitted. Double-check the RPC method reference in the surrounding text for accuracy.
28669-28681: RevisionHeight Clarification in Connection Consensus State
The documentation here confirms that the JSON marshaller’s behavior (excludingomitempty) applies to bothrevision_numberandrevision_height. The detail is precise and consistent.
29197-29209: RevisionHeight and Height Type Description Update
The update describes the behavior of a monotonically increasing Height data type while explaining thatRevisionHeightresets (with JSON zero emission). The explanation is clear and beneficial for API users.
29727-29739: Clarification on Height as a Monotonically Increasing Data Type
The added explanation helps distinguish between the continuously increasing Height and the reset behavior of RevisionHeight. The text is consistent with similar updates elsewhere.
31223-31235: RevisionHeight Documentation Update for Height Data Type
This hunk reiterates that the JSON marshaller always emits a value forRevisionHeightregardless of resets. The documentation is clear, although the repeated text might be abstracted into a shared note.
31319-31331: Reinforced RevisionHeight Explanation in QueryClientConnectionsResponse
The explanatory text is consistent with the other changes regardingRevisionHeightand helps maintain clarity in the API’s response definitions.
31686-31698: RevisionHeight Update for QueryConnectionsResponse
This change reinforces the behavior that theRevisionHeightfield always appears in responses (with a zero value if reset).
32087-32099: RevisionHeight Note in QueryConnectionResponse
The updated documentation clarifies the handling of theRevisionHeightfield for the Query/Connection RPC, which is consistent with similar sections across the file.
32542-32554: RevisionHeight Explanation for QueryConnectionClientStateResponse
The new documentation clarifies the behavior ofRevisionHeightfor the ConnectionClientState response. The note is clear and consistent.
32979-32991: RevisionHeight Clarification in QueryConnectionConsensusStateResponse
This hunk documents that the JSON marshaller explicitly excludesomitemptyso that a zeroRevisionHeightis always output. The change is clear and follows the established pattern.
37072-37079: Endpoint Update: BaseDenom Parameter Update
This hunk appears to be part of the update for the/opinit/opchild/v1/base_denomendpoint. Please verify that the endpoint’s documentation now correctly reflects any changes in parameter location or type.
37282-37289: Parameter Location Change for 'denom'
Thedenomparameter has been updated from a path parameter to a query parameter. This change is clearly documented. Ensure that client implementations and any related tests are updated accordingly.
37342-37349: Chain Type Enumeration Update
The enum for the target chain type now includesUNSPECIFIED,INITIA, andCELESTIA(with the default set toUNSPECIFIED). This update appears correct and consistent with the domain terminology.
37357-37363: Finalization Period and Submission Start Height Definitions
The updated definitions forfinalization_periodandsubmission_start_heightprovide clearer descriptions. Please ensure these align with backend requirements.
38058-38067: Addition of hook_max_gas to QueryParamsResponse
A new propertyhook_max_gasis added with type string (formatted as uint64) and a descriptive title. The update is clear; verify that the data type aligns with the service’s expectations.
46074-46150: New Endpoint: GetCurrencyPairMappingList
This hunk adds the/connect/oracle/v2/get_currency_pair_mapping_listendpoint along with its detailed response schema. The new response type definition forCurrencyPairMappingis comprehensive—please ensure it is consistent with similar endpoints and that field descriptions are accurate.
46557-46564: Endpoint Summary Update for MarketMap
A minor update in the MarketMap endpoint summary. The description has been improved; please confirm that the endpoint behavior matches the summarized functionality.
46745-46912: New Endpoint: Markets
This hunk introduces the/connect/marketmap/v2/marketsendpoint with a detailed response schema for market data, including nested properties for tickers and provider configurations. The documentation is comprehensive—ensure consistency in formatting and descriptions, and that nested objects correctly reflect the actual data structure.
65658-65670: RevisionHeight Update in QueryChannelClientStateResponse
This update carries the standard explanation for theRevisionHeightbehavior in this RPC response. It is consistent with previous blocks.
65920-65932: RevisionHeight Note with Timestamp in Response
The update clearly documents the expected behavior ofRevisionHeightalong with timestamp information. The information is consistent with similar endpoints.
66063-66075: QueryChannelResponse RevisionHeight Documentation
The standard explanatory text for theRevisionHeightfield is applied to this response type. The documentation is clear and consistent.
66381-66393: RevisionHeight Note in QueryConnectionChannelsResponse
The updated documentation here follows the same standard as other endpoints, ensuring clarity about the reset behavior ofRevisionHeight.
66430-66442: RevisionHeight Update for QueryNextSequenceReceiveResponse
The changes document the behavior ofRevisionHeighteffectively in the context of receiving sequences. The standard note is maintained accurately.
66479-66491: RevisionHeight Explanation in QueryNextSequenceSendResponse
The text update here is consistent with earlier blocks and explains the behavior of the JSON marshaller regardingRevisionHeight.
66528-66540: RevisionHeight Documentation Addendum in QueryPacketAcknowledgementResponse
The additional explanation clarifies that the omitting behavior is overridden. The note is consistent and reinforces the expected behavior.
66625-66637: RevisionHeight Note in QueryPacketAcknowledgementsResponse
The updated documentation provides clarity regarding the handling ofRevisionHeightand is in line with other similar sections.
66674-66686: RevisionHeight Documentation in QueryPacketCommitmentResponse
This section concisely reiterates that the JSON marshaller will always output a value forRevisionHeight. The explanation is clear and consistent.
66774-66786: RevisionHeight Update in QueryPacketCommitmentsResponse
The documentation here reinforces the expected behavior forRevisionHeightin the packet commitments response. The update is clear and follows the established pattern.
66822-66834: RevisionHeight Note in QueryPacketReceiptResponse
The explanatory text here is in line with the rest of the document, clarifying that the JSON marshaller always emits zero values when necessary.
66873-66885: RevisionHeight Documentation for QueryUnreceivedAcksResponse
The updated text correctly clarifies the behavior ofRevisionHeightfor this endpoint. It follows the same detailed explanation seen throughout the file.
66920-66932: RevisionHeight Update in QueryUnreceivedPacketCommitmentsResponse
This hunk reinforces the documentation thatRevisionHeightis always emitted, despite resets. The note is clear and consistent.
66983-66995: RevisionHeight Explanation for QueryUpgradeErrorResponse
The text here reiterates the JSON marshaller behavior forRevisionHeightin upgrade error responses. The explanation is consistent with previous sections.
67056-67068: RevisionHeight and Timestamp Details in Response
The added details regarding the timestamp formatting along with the RevisionHeight behavior provide further clarity. The documentation is thorough.
67191-67203: RevisionHeight and Timestamp Explanation in Response
The documentation clearly reaffirms that the JSON marshaller always outputs a value forRevisionHeight, with proper timestamp formatting.
67345-67369: Extended Context for Height and RevisionHeight Explanation
The changes here provide extended details on how the revision number is incremented when the height resets. The clarification is thorough and beneficial for understanding the underlying consensus logic.
67576-67588: RevisionHeight Clarification in Consensus State Response
The documentation here states that the JSON marshaller emits zero values forrevision_numberandrevision_heightwhen reset. The note is clear and consistent with previous updates.
67994-68006: RevisionHeight Note in QueryClientStateResponse
This update reiterates the behavior forRevisionHeightin the client state response. The documentation is consistent and clear.
68275-68287: Reiteration of Height Type Definition with RevisionHeight Note
The updated description reinforces that while Height is monotonically increasing, theRevisionHeightmay reset—yet will always be emitted in full. Clear and informative.
69174-69186: Clarification on Height as a Monotonically Increasing Data Type
The documentation here effectively distinguishes between the continuously increasing Height and the reset behavior of the RevisionHeight. The explanation is accurate and clear.
69502-69514: RevisionHeight Notation in QueryClientConnectionsResponse
This update reconfirms the handling ofRevisionHeightfor client connection responses. The explanation is consistent with the other sections.
69728-69740: RevisionHeight Documentation in QueryConnectionClientStateResponse
The updated text is consistent with earlier revisions regardingRevisionHeight. Ensure that it is uniformly applied across all responses.
69941-69953: RevisionHeight Explanation in QueryConnectionConsensusStateResponse
The documentation clearly states the behavior ofRevisionHeightfor this response type, aligning well with the standard explanation used throughout the spec.
70098-70110: RevisionHeight Note in QueryConnectionResponse
The update documents the expected behavior of theRevisionHeightfield alongside a standard JSON tag explanation. The details are accurate and matching other sections.
70253-70265: RevisionHeight Documentation in QueryConnectionsResponse
This hunk reaffirms that the JSON marshaller always includes a value forRevisionHeight, even if it resets. The explanation is clear and consistent.
71413-71422: Enum Description Updated for Target Chain Type
The description for the target chain type now clearly lists the allowed enum values (UNSPECIFIED,INITIA,CELESTIA) withUNSPECIFIEDas the default. Verify that these values are consistent with other parts of the system.
71427-71433: Finalization Period and Submission Start Height Details
The parameter descriptions forfinalization_periodandsubmission_start_heightare concise and clear. Please ensure that these definitions match the backend’s requirements.
71485-71494: Updated Props in QueryParamsResponse
A new propertyhook_max_gashas been added with the proper type (stringwith formatuint64) and a descriptive title. The update meets documentation standards.
71546-71554: Chain Type Enum Reiteration in opinit.opchild.v1
The enum definition for the target chain type is reiterated here. The values are clear and consistent with earlier definitions—ensure that no conflicting definitions exist elsewhere.
71560-71566: Parameter Definitions: Finalization Period and Submission Start Height
The updated definitions for these parameters continue to be clear and consistent with the overall API documentation.
71648-71657: Revision and New Parameter Update in QueryValidatorResponse
The documentation forQueryValidatorResponsenow includes a note on allowed zero-fee addresses and details regardinghook_max_gas. The update is clear and integrates well with the other parameter descriptions.
72286-72304: Chain Type Enum and BatchInfo Description Update
This hunk updates the enum values for chain types and clarifies the BatchInfo definition. The descriptions and default values are clear; please verify that they match the backend specifications.
72324-72333: Additional Enum for Target Chain Type in opinit.ophost.v1
The repeated enum definition here for the target chain type appears consistent with earlier definitions. Confirm that any redundancy is intentional and that the values remain in sync throughout the documentation.
72338-72344: Finalization Period and Submission Start Height in opinit.ophost.v1
The updated parameter definitions in this section are clear and consistent with similar sections elsewhere in the file.
74492-74517: New Response Type: CurrencyPairMapping
A new response type (connect.oracle.v2.CurrencyPairMapping) is introduced with clearly defined properties. The description is comprehensive; verify that the field types and formats match the actual data model.
74534-74572: New Response Types: GetAllCurrencyPairsResponse & GetCurrencyPairMappingListResponse
These new response types are defined with detailed properties and schemas. The explanations provided help API consumers understand the data structure—ensure that field descriptions align with the implementation.
75282-75417: New Response Type: MarketsResponse in Marketmap Module
Theconnect.marketmap.v2.MarketsResponseschema is introduced with an extensive set of nested properties describing market data. The documentation is comprehensive; ensure that all nested fields correctly reflect the underlying data structures and that descriptions are precise.Dockerfile.arm64 (1)
1-1: Base Image Update for Go 1.23
The base image is now updated toarm64v8/golang:1.23-bullseye, which is consistent with the global upgrade across all build environments. Please ensure that all projects’ dependencies work correctly with this updated image.README.md (1)
7-7: Prerequisites Go Version Update Clarification
The diff shows a change (removal) on the line listing the Go version in the prerequisites section. Please verify that the intended update (presumably updating from a previous version likeGo v1.22.7+toGo v1.23.1+) is correctly applied and clearly communicated to users..github/workflows/build-linux-amd64.yml (1)
15-15: Go Version Updated in Linux AMD64 Build Workflow
The workflow now specifiesgo-version: "1.23", aligning with similar updates in other workflow files. This change ensures a consistent build environment across architectures..github/workflows/test.yml (1)
30-30: Test Workflow Go Version Upgrade
The update togo-version: 1.23in the test workflow ensures that the testing environment aligns with the global upgrade. This consistency helps avoid potential version mismatches during CI.Dockerfile (1)
1-1: Dockerfile Base Image Upgrade
The Dockerfile now usesFROM golang:1.23-alpine AS go-builderinstead of the oldergolang:1.22-alpine3.19. This change not only upgrades the Go version but also shifts to a newer Alpine base. Confirm that the Alpine environment and dependencies are fully compatible with this change..github/workflows/build-darwin-arm64.yml (2)
17-17: Go Version Update ConfirmationThe GitHub Actions step now correctly specifies
go-version: "1.23", in line with the overall project upgrade.
19-26: Environment Variables and Shell Script BlockThe environment variables (e.g.,
MINIWASM_NETWORK_NAME,GOARCH,GOOS, etc.) are properly set for the Darwin ARM64 build. Please verify these values against your platform requirements as future adjustments might be needed if additional architectures are supported.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 22-22: trailing spaces
(trailing-spaces)
[error] 23-23: trailing spaces
(trailing-spaces)
.github/workflows/build-darwin-amd64.yml (2)
18-18: Go Version Update ConfirmationThe update to
go-version: "1.23"is correctly applied in this workflow. It ensures consistency with other workflow files and the updated Go environment.
20-34: Environment Variables and Dependency SetupThe environment variable block successfully sets variables such as
MINIWASM_NETWORK_NAME,GOARCH,GOOS,VERSION,ARCH_NAME, and retrievesWASMVM_VERSION. Everything appears correct. Still, ensure that the value ofARCH_NAME(set tox86_64) is compatible with the rest of your packaging and release steps.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 23-23: trailing spaces
(trailing-spaces)
go.mod (10)
3-6: Go Version and Toolchain UpgradeThe file now specifies
go 1.23.1andtoolchain go1.23.2. This upgrade is consistent with the updates in your GitHub workflows and Dockerfiles.
23-24: CometBFT Dependency UpdateThe version for
github.com/cometbft/cometbfthas been bumped tov0.38.17. This update aligns with the PR’s dependency upgrade goals.
32-32: IBC-Go Dependency UpdateThe
github.com/cosmos/ibc-go/v8dependency is updated tov8.5.3. Make sure that this update does not introduce breaking changes in the IBC-related modules within your application.
38-39: Initia Package UpdatesBoth
github.com/initia-labs/OPinitandgithub.com/initia-labs/initiahave been updated tov0.7.0. These changes satisfy the dependency bump goals and should be verified with the integration tests to ensure compatibility.
45-45: Forwarding Dependency UpdateThe update to
github.com/noble-assets/forwarding/v2(versionv2.0.0) is noted. Confirm that any API or behavior changes in the new version are fully accounted for in your usage.
49-50: Skip-MEV Package UpdatesThe versions for
github.com/skip-mev/block-sdk/v2andgithub.com/skip-mev/connect/v2have been updated tov2.1.5andv2.3.0respectively. These changes are consistent with the dependency bump objectives, but thorough integration testing is recommended.
54-57: Additional Dependency UpdatesMultiple dependencies such as
github.com/stretchr/testify,google.golang.org/grpc, and others have been updated. Ensure all tests pass and perform a regression check as these upgrades can sometimes introduce subtle behavior changes or compatibility issues.
232-245: OpenTelemetry and x Packages UpdatesThe updates for the OpenTelemetry packages (e.g.,
go.opentelemetry.io/otel,otel/metric,otel/trace) as well as updates forgolang.org/x/crypto,x/net,x/oauth2, andx/texthave been applied. Please run the test suite thoroughly to ensure that these versions integrate well with your monitoring and utility code.
261-277: Replace Directives VerificationThe replace directives at the end of the file (lines 261–277) have been updated to use the cosmos and initia forks for certain dependencies. These changes help address known vulnerabilities and compatibility issues. Verify that these replacements do not inadvertently affect any other dependent modules.
284-288: Initia Custom ReplacementsThe custom replacements for
github.com/cometbft/cometbftandgithub.com/cosmos/ibc-go/v8now point to the forked versions from initia-labs. Make sure that the changes in these forks are well documented and that any breaking changes are communicated to the team.
| RevisionHeight | ||
|
|
||
| gets reset | ||
|
|
||
|
|
||
| Please note that json tags for generated Go code are | ||
| overridden to explicitly exclude the omitempty jsontag. | ||
|
|
||
| This enforces the Go json marshaller to always emit zero | ||
| values for both revision_number and revision_height. | ||
| title: |- | ||
| QueryPacketAcknowledgemetsResponse is the request type for the | ||
| Query/QueryPacketAcknowledgements RPC method |
There was a problem hiding this comment.
RevisionHeight Note for QueryPacketAcknowledgemetsResponse
This hunk provides explanatory text regarding the RevisionHeight field for the QueryPacketAcknowledgemetsResponse. Note: The term “Acknowledgemets” appears likely to be a typo—please verify and correct if necessary (e.g. to “Acknowledgements”).
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #92 +/- ##
==========================================
+ Coverage 64.84% 64.89% +0.04%
==========================================
Files 39 39
Lines 3172 3176 +4
==========================================
+ Hits 2057 2061 +4
Misses 938 938
Partials 177 177
|
Description
cometbft: v0.38.17
initia: v0.7.0
opinit: v0.7.0
ibc-go: v8.5.3
forwarding: v2.0.0
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!in the type prefix if API or client breaking changeReviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
Summary by CodeRabbit
New Features
Documentation
Chores