v0.50.x EVM meets cometbft v1 #56
Conversation
* Add CometBFT v1 buf registry commit to buf.yaml * Update tendermint to comet import in proto files * Replace tendermint to comet imports in Go files * Remove deprecated sr25519 support starting from CometBFT v1.0.1 * Update SDK go.mod to use local ./api, which is upgraded to Comet v1, instead of cosmossdk.io/api v0.7.5 * Generate proto and pulsar files and remove tendermint from ./proto
* Remove go toolchain from go.mod files
* Generate pulsar files * Fix ABCI unit test in baseapp * Fix genesis tests * Remove Go toolchains * Fix remaining breaking changes of Comet v1 ABCI types
Co-authored-by: Julien Robert <[email protected]>
…mos#20266) Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…itSync bool and is never tested * Fix building errors in integration tests introduced by f173a77 which breaks all integration tests using the bank keeper * Remove deprecated MsgEditValidator ValidateBasic function which was breaking some related CLI test in x/staking
* Update base block gas in block gas tests
* Add missing bank module to simapp's EndBlockers causing test-simapp to fail in GH workflow
…stTxSync in Comet V1
refresh go.mod and go.sum dependencies.
* missing merge in auth * gogoproto extension double-reg issue * grpc/pulsar re-generated (Note: missed that during #53) * minimise diff to only cometbft1 related changes * fix preblocker events (keep old behavior) * fix store tests
WalkthroughThis update performs a comprehensive migration from deprecated Tendermint (TM) protobuf types and APIs to their modern CometBFT equivalents across the codebase. All ABCI request and response types, block, validator, and crypto types are updated to use the new CometBFT v1 protobuf definitions. Method signatures, struct fields, and type aliases are revised accordingly in both application and test code. Several generated files for legacy Tendermint types are removed. New features are introduced, such as the Changes
Sequence Diagram(s)CheckTx Handler ExtensionsequenceDiagram
participant Client
participant CometBFT
participant BaseApp
participant CheckTxHandler
participant AnteHandlers
Client->>CometBFT: Submit Tx (via P2P/RPC)
CometBFT->>BaseApp: CheckTx(txBytes)
alt Custom CheckTxHandler set
BaseApp->>CheckTxHandler: Handle(txBytes)
CheckTxHandler->>BaseApp: Return (decodedTx, err)
BaseApp->>AnteHandlers: Validate(decodedTx)
else No custom handler
BaseApp->>AnteHandlers: Validate(decodedTx)
end
AnteHandlers-->>BaseApp: Validation result
BaseApp-->>CometBFT: CheckTxResponse
AutoCLI Command Generation (Simplified)sequenceDiagram
participant AppModule
participant AutoCLI Builder
participant RootCommand
AppModule->>AutoCLI Builder: Provide AutoCLIOptions()
AutoCLI Builder->>RootCommand: EnhanceRootCommand()
AutoCLI Builder->>RootCommand: Add generated commands/flags
RootCommand-->>User: Expose CLI with customizations
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 golangci-lint (1.64.8)level=warning msg="[config_reader] The configuration option ✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| break | ||
| } | ||
| } | ||
| intStringLen := int(stringLen) |
Check failure
Code scanning / gosec
integer overflow conversion uint64 -> uint8 Error
| break | ||
| } | ||
| } | ||
| intStringLen := int(stringLen) |
Check failure
Code scanning / gosec
integer overflow conversion uint64 -> uint8 Error
| break | ||
| } | ||
| } | ||
| intStringLen := int(stringLen) |
Check failure
Code scanning / gosec
integer overflow conversion uint64 -> uint8 Error
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🔭 Outside diff range comments (5)
baseapp/oe/optimistic_execution.go (1)
85-99: 🛠️ Refactor suggestion
⚠️ Potential issueNil-pointer risk when OE hasn’t been initialised.
Executesetsoe.request, but other public methods (AbortIfNeeded,WaitResult)
useoe.requestoroe.stopChwithout verifying thatExecutehas run.
IfAbortIfNeededis called beforeExecute,oe.requestisnilandbytes.Equal(oe.request.Hash, reqHash)will dereference a
nilpointer and panic.Minimal guard:
func (oe *OptimisticExecution) AbortIfNeeded(reqHash []byte) bool { if oe == nil { return false } oe.mtx.Lock() defer oe.mtx.Unlock() + if oe.request == nil { + return false // OE not started, nothing to abort + }Apply a similar check in
WaitResultto avoid blocking on anilchannel.api/cosmos/consensus/v1/tx.pulsar.go (1)
1290-1304:⚠️ Potential issue
MsgUpdateParamsgains two nullable pointers – don’t forget runtime validation.
Synchrony(field 6) andFeature(field 7) are now part of the message, but the server-sideValidateBasic, keeperUpdateParams, and any param-sanity checks have not been updated in this generated file.
Unless higher-level code is extended, a malformed transaction could:
- Provide neither field (both pointers
nil) and still pass basic validation.- Provide empty parameter objects that violate consensus rules.
Please review the non-generated logic (likely under
x/consensus/keeper/andx/consensus/types/validation.go) and enforce:if msg.Synchrony == nil || err := validateSynchrony(msg.Synchrony); err != nil { … }Analogous checks should be added for
Feature.baseapp/abci_utils.go (2)
82-90:⚠️ Potential issueIncorrect voting-power denominator skews 2/3-threshold check
totalVPis incremented for all validators, whilesumVPonly counts those withBlockIDFlagCommit.
If the proposer skipped or was absent (i.e. flag ≠ Commit) you can spuriously reject a block becausesumVP < requiredVP, even though ≥2/3 of the committers provided valid extensions.- for _, vote := range extCommit.Votes { - totalVP += vote.Validator.Power + for _, vote := range extCommit.Votes { // Only check + include power if the vote is a commit vote. … if vote.BlockIdFlag != cmtproto.BlockIDFlagCommit { continue } + totalVP += vote.Validator.PowerMove the
totalVPaccumulator into the conditional (or maintain a separatecommitVP) so the denominator matches the numerator.
Otherwise chains with >⅓ non-commit votes will never reach the threshold.
168-173: 🛠️ Refactor suggestionComparator can overflow on large Power differences
-int(vote1.Validator.Power - vote2.Validator.Power)casts theint64
difference to anint, risking overflow on 32-bit platforms or when voting
power exceedsmath.MaxInt. Usecmplogic without subtraction:return intcmp(vote1.Validator.Power, vote2.Validator.Power) func intcmp(a, b int64) int { switch { case a > b: return -1 // descending case a < b: return 1 default: return 0 } }This avoids undefined behaviour and keeps the ordering correct.
baseapp/abci.go (1)
1071-1097: 🛠️ Refactor suggestionUnsafe cast between
storetypes.ResponseQueryandabci.QueryResponse
storetypes.ResponseQueryandabci.QueryResponseare distinct structs defined
in different protobuf packages. A direct type-cast relies on Go’s unsafe
assumption that both layouts are byte-for-byte identical, which is not
guaranteed after the CometBFT v1 migration. A single field re-ordering will
cause memory corruption at runtime.- abciResp := abci.QueryResponse(*resp) - - return &abciResp + return &abci.QueryResponse{ + Code: resp.Code, + Codespace: resp.Codespace, + Log: resp.Log, + Info: resp.Info, + Index: resp.Index, + Key: resp.Key, + Value: resp.Value, + ProofOps: resp.ProofOps, + Height: resp.Height, + }
♻️ Duplicate comments (2)
api/cosmos/base/tendermint/v1beta1/query.pulsar.go (2)
4611-4611: Duplicate of pointer instantiation style
Please usenew(v1.BlockID)instead of&v1.BlockID{}for consistency with othernew(...)calls.
4647-4647: Duplicate of pointer instantiation style
Consider switching tonew(v1.Block)to match the instantiation style used elsewhere.
🧹 Nitpick comments (15)
orm/go.mod (1)
26-35: Prune unused indirect dependencies
A number of new indirect dependencies (e.g.,github.com/cockroachdb/fifo,github.com/munnerz/goautoneg) have appeared. Consider runninggo mod tidyfollowed bygo mod whyon these modules to ensure they’re genuinely required, and remove any that transitively bloat the module.go.mod (2)
73-80: Review indirect dependency updates
The indirect dependencies block has been updated with several new entries (e.g.,github.com/DataDog/zstd,github.com/Microsoft/go-winio). After ago mod tidy, consider auditing these transitive dependencies for necessity and potential licensing or security implications.
200-218: Local replace directives for CometBFT integration
Thereplacedirectives point to local forks ofcometbft/cometbftand its API. These are required for the v1.0.1-inj integration, but remember to revert or update them to official upstream versions before the final release.CHANGELOG.md (1)
39-42: Group Unreleased entries under a feature stanza
The Unreleased section has a new entry forCheckTxHandler, but it isn’t grouped under a heading like### Features. For consistency with the rest of the changelog, please add a### Features(or appropriate stanza) header above this entry.docs/docs/learn/advanced/00-baseapp.md (1)
435-435: Documentation updated to reflect new type namesThe parameter type in the documentation has been correctly updated from
abci.RequestInitChaintoabci.InitChainRequestto align with the CometBFT v1 API changes.Consider slightly rewording this line to improve readability: "...calls the
initChainer()of the application to initialize the main state from the genesis file..."🧰 Tools
🪛 LanguageTool
[style] ~435-~435: Consider a shorter alternative to avoid wordiness.
Context: ...tomy.md#initchainer) of the application in order to initialize the main state of the applic...(IN_ORDER_TO_PREMIUM)
docs/docs/build/abci/04-checktx.md (1)
23-23: Fix typo in description of CheckTxHandlerThere's a minor typo in the description.
-`CheckTxHandler` allows users to extend the logic of `CheckTx`. `CheckTxHandler` is called by pasding context and the transaction bytes received through ABCI. It is required that the handler returns deterministic results given the same transaction bytes. +`CheckTxHandler` allows users to extend the logic of `CheckTx`. `CheckTxHandler` is called by passing context and the transaction bytes received through ABCI. It is required that the handler returns deterministic results given the same transaction bytes.docs/docs/building-modules/10-autocli.md (4)
20-21: Prefer “CLI” over “CLI interface”.The word “interface” is redundant because the “I” in CLI already stands for “interface”.
Consider shortening to simply “…add a CLI to your application…”.🧰 Tools
🪛 LanguageTool
[style] ~20-~20: This phrase is redundant (‘I’ stands for ‘interface’). Use simply “CLI”.
Context: ...s. This means that you can easily add a CLI interface to your application without having to m...(ACRONYM_TAUTOLOGY)
27-30: Grammar & clarity – re-phrase step descriptions.Current text is slightly awkward (“Configure how behave
autoclicommand generation…”, “struct to specifies…”). A lighter wording improves readability:-2. Configure how behave `autocli` command generation, by implementing the - `func (am AppModule) AutoCLIOptions() *autocliv1.ModuleOptions` method on - the module. -3. Use the `autocli.AppOptions` struct to specifies the modules you defined. +2. Configure how `autocli` should generate commands by implementing + `func (am AppModule) AutoCLIOptions() *autocliv1.ModuleOptions`. +3. Use `autocli.AppOptions` to specify the modules you defined.🧰 Tools
🪛 LanguageTool
[uncategorized] ~27-~27: Possible missing preposition found.
Context: ....AppModuleinterface. 2. Configure how behaveautocli` command generation, by implem...(AI_HYDRA_LEO_MISSING_TO)
[uncategorized] ~28-~28: This verb does not appear to agree with the subject. Consider using a different form.
Context: ... Use theautocli.AppOptionsstruct to specifies the modules you defined. If you are usi...(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
104-106: Missing comma after introductory clause.Add a comma after “In the example code” to avoid a run-on sentence.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~104-~104: Possible missing comma found.
Context: ...is defined in theappmodule.AppModuleimplementation located in thex/gov/autocli.gofile....(AI_HYDRA_LEO_MISSING_COMMA)
151-154: Redundant wording – “CLI interfaces”.Same redundancy as earlier; “CLI” is sufficient.
🧰 Tools
🪛 LanguageTool
[style] ~153-~153: This phrase is redundant (‘I’ stands for ‘interfaces’). Use simply “CLIs”.
Context: ...autocliis a powerful tool for adding CLI interfaces to your Cosmos SDK-based applications. ...(ACRONYM_TAUTOLOGY)
api/cosmos/autocli/v1/options.pulsar.go (2)
4501-4506: Doc-comment wording & key mismatchThe comment uses the plural phrase
enhance_custom_commandswhile the field and JSON/proto tag are singularenhance_custom_command. This can confuse users who read Godoc/Swagger and could lead to incorrect struct‐tag references in hand-written code.-// enhance_custom_commands specifies whether to skip the service when generating commands, if a custom command already -// exists, or enhance the existing command. If set to true, the custom command will be enhanced with the services from -// gRPC. otherwise when a custom command exists, no commands will be generated for the service. +// enhance_custom_command specifies whether the generator should skip services that already have a +// user-provided command, or instead *enhance* that custom command. +// When true, any existing custom command is augmented with auto-generated RPC sub-commands; +// when false, the generator skips emission for that service entirely.
4816-4822: Add runtime validation for mutually-exclusivevarargsandoptionalThe proto comments explicitly state that
varargsandoptionalcannot both be true, yet no guard enforces this. An invalid combination will silently marshal and could crash downstream CLI construction.Consider centralising a light-weight validator, e.g. in the AutoCLI builder, to fail fast:
func (p *PositionalArgDescriptor) Validate() error { if p.Varargs && p.Optional { return fmt.Errorf("proto_field %q cannot be both varargs and optional", p.ProtoField) } return nil }and call it during CLI schema loading.
api/cosmos/base/tendermint/v1beta1/query.pulsar.go (2)
3662-3662: Consistent pointer instantiation
Consider usingnew(v1.BlockID)instead of&v1.BlockID{}to match other instantiation patterns in this file.
3698-3698: Consistent pointer instantiation
Usenew(v1.Block)rather than&v1.Block{}for uniformity across the generated code.api/cosmos/consensus/v1/tx.pulsar.go (1)
806-877: Nested unmarshal branches: duplicated error-handling boilerplate can be factored.The new switch cases for fields 6 & 7 repeat the same
msglen,postIndex, boundary checks, andoptions.Unmarshalpattern present in prior cases.
To curb future maintenance burden, consider extracting the “message field decode” logic into a helper (e.g.,decodeSubMessage[T any]) in the code-generation template.Purely a generator NIT, no action required for this PR.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (30)
api/cosmos/staking/v1beta1/query_grpc.pb.gois excluded by!**/*.pb.goapi/cosmos/staking/v1beta1/tx_grpc.pb.gois excluded by!**/*.pb.goapi/go.sumis excluded by!**/*.sumapi/tendermint/abci/types_grpc.pb.gois excluded by!**/*.pb.goclient/grpc/cmtservice/query.pb.gois excluded by!**/*.pb.goclient/grpc/cmtservice/types.pb.gois excluded by!**/*.pb.gogo.sumis excluded by!**/*.sumorm/go.sumis excluded by!**/*.sumorm/internal/testpb/bank.pb.gois excluded by!**/*.pb.goorm/internal/testpb/bank_query.pb.gois excluded by!**/*.pb.goorm/internal/testpb/bank_query_grpc.pb.gois excluded by!**/*.pb.goorm/internal/testpb/test_schema.pb.gois excluded by!**/*.pb.goorm/internal/testpb/test_schema_query.pb.gois excluded by!**/*.pb.goorm/internal/testpb/test_schema_query_grpc.pb.gois excluded by!**/*.pb.goproto/buf.lockis excluded by!**/*.locksimapp/go.sumis excluded by!**/*.sumstore/go.sumis excluded by!**/*.sumstore/streaming/abci/grpc.pb.gois excluded by!**/*.pb.gostore/types/listening.pb.gois excluded by!**/*.pb.gotests/go.sumis excluded by!**/*.sumtypes/abci.pb.gois excluded by!**/*.pb.gotypes/tx/service.pb.gois excluded by!**/*.pb.gox/circuit/go.sumis excluded by!**/*.sumx/consensus/types/query.pb.gois excluded by!**/*.pb.gox/consensus/types/tx.pb.gois excluded by!**/*.pb.gox/evidence/go.sumis excluded by!**/*.sumx/feegrant/go.sumis excluded by!**/*.sumx/nft/go.sumis excluded by!**/*.sumx/staking/types/staking.pb.gois excluded by!**/*.pb.gox/upgrade/go.sumis excluded by!**/*.sum
📒 Files selected for processing (61)
CHANGELOG.md(1 hunks)api/cosmos/app/runtime/v1alpha1/module.pulsar.go(17 hunks)api/cosmos/autocli/v1/options.pulsar.go(29 hunks)api/cosmos/base/abci/v1beta1/abci.pulsar.go(27 hunks)api/cosmos/base/tendermint/v1beta1/query.pulsar.go(24 hunks)api/cosmos/base/tendermint/v1beta1/types.pulsar.go(21 hunks)api/cosmos/consensus/v1/query.pulsar.go(9 hunks)api/cosmos/consensus/v1/tx.pulsar.go(20 hunks)api/cosmos/staking/v1beta1/genesis.pulsar.go(16 hunks)api/cosmos/staking/v1beta1/staking.pulsar.go(18 hunks)api/cosmos/store/streaming/abci/grpc.pulsar.go(16 hunks)api/cosmos/store/v1beta1/listening.pulsar.go(11 hunks)api/cosmos/tx/v1beta1/service.pulsar.go(11 hunks)api/go.mod(1 hunks)api/tendermint/crypto/keys.pulsar.go(0 hunks)api/tendermint/libs/bits/types.pulsar.go(0 hunks)api/tendermint/types/block.pulsar.go(0 hunks)api/tendermint/types/validator.pulsar.go(0 hunks)api/tendermint/version/types.pulsar.go(0 hunks)baseapp/abci.go(31 hunks)baseapp/abci_test.go(91 hunks)baseapp/abci_utils.go(8 hunks)baseapp/abci_utils_test.go(7 hunks)baseapp/baseapp.go(10 hunks)baseapp/baseapp_test.go(27 hunks)baseapp/block_gas_test.go(2 hunks)baseapp/grpcrouter.go(3 hunks)baseapp/grpcrouter_helpers.go(1 hunks)baseapp/info.go(2 hunks)baseapp/msg_service_router_test.go(2 hunks)baseapp/oe/optimistic_execution.go(4 hunks)baseapp/oe/optimistic_execution_test.go(1 hunks)baseapp/options.go(1 hunks)baseapp/params.go(1 hunks)baseapp/params_legacy.go(1 hunks)baseapp/snapshot_test.go(9 hunks)baseapp/streaming_test.go(7 hunks)baseapp/test_helpers.go(4 hunks)baseapp/testutil/mock/mocks.go(1 hunks)baseapp/utils_test.go(1 hunks)client/grpc/cmtservice/block.go(1 hunks)client/grpc/cmtservice/service.go(2 hunks)client/grpc/cmtservice/types.go(1 hunks)client/grpc/cmtservice/util.go(1 hunks)client/grpc_query.go(1 hunks)client/grpc_query_test.go(1 hunks)client/query.go(5 hunks)client/rpc/block.go(1 hunks)client/rpc/rpc_test.go(1 hunks)client/rpc/tx.go(3 hunks)client/utils.go(1 hunks)client/v2/CHANGELOG.md(1 hunks)crypto/codec/amino.go(0 hunks)crypto/codec/cmt.go(1 hunks)crypto/keys/multisig/codec.go(0 hunks)docs/docs/build/abci/04-checktx.md(1 hunks)docs/docs/building-modules/10-autocli.md(1 hunks)docs/docs/learn/advanced/00-baseapp.md(2 hunks)docs/docs/learn/advanced/15-upgrade.md(1 hunks)go.mod(9 hunks)orm/go.mod(1 hunks)
💤 Files with no reviewable changes (7)
- crypto/codec/amino.go
- crypto/keys/multisig/codec.go
- api/tendermint/libs/bits/types.pulsar.go
- api/tendermint/version/types.pulsar.go
- api/tendermint/types/validator.pulsar.go
- api/tendermint/crypto/keys.pulsar.go
- api/tendermint/types/block.pulsar.go
👮 Files not reviewed due to content moderation or server errors (1)
- api/cosmos/tx/v1beta1/service.pulsar.go
🧰 Additional context used
🧬 Code Graph Analysis (11)
client/grpc_query_test.go (1)
testutil/sims/app_helpers.go (1)
DefaultConsensusParams(36-51)
baseapp/options.go (2)
baseapp/baseapp.go (1)
BaseApp(67-209)types/abci.go (1)
CheckTxHandler(29-29)
baseapp/oe/optimistic_execution_test.go (3)
baseapp/abci_test.go (1)
TestOptimisticExecution(2357-2396)baseapp/oe/optimistic_execution.go (1)
NewOptimisticExecution(39-46)log/logger.go (1)
NewNopLogger(119-122)
baseapp/test_helpers.go (1)
baseapp/baseapp.go (1)
BaseApp(67-209)
baseapp/abci_utils_test.go (1)
types/abci.go (1)
PrepareProposalHandler(24-24)
api/cosmos/staking/v1beta1/genesis.pulsar.go (1)
x/staking/types/genesis.pb.go (3)
GenesisState(30-52)GenesisState(56-56)GenesisState(57-59)
baseapp/oe/optimistic_execution.go (2)
client/grpc_query.go (1)
Context(125-127)server/cmd/execute.go (1)
Execute(19-35)
api/cosmos/staking/v1beta1/staking.pulsar.go (1)
x/staking/types/staking.pb.go (9)
Validator(349-378)Validator(382-382)Validator(383-385)HistoricalInfo(115-118)HistoricalInfo(122-122)HistoricalInfo(123-125)ValidatorUpdates(1204-1206)ValidatorUpdates(1210-1210)ValidatorUpdates(1211-1213)
baseapp/abci_utils.go (3)
types/context.go (1)
Context(41-73)types/abci.go (4)
PrepareProposalHandler(24-24)ProcessProposalHandler(21-21)ExtendVoteHandler(32-32)VerifyVoteExtensionHandler(36-36)simapp/abci.go (1)
VoteExtension(23-27)
api/cosmos/consensus/v1/tx.pulsar.go (1)
x/consensus/types/tx.pb.go (3)
MsgUpdateParams(35-50)MsgUpdateParams(54-54)MsgUpdateParams(55-57)
api/cosmos/tx/v1beta1/service.pulsar.go (1)
types/tx/service.pb.go (3)
GetBlockWithTxsResponse(666-673)GetBlockWithTxsResponse(677-677)GetBlockWithTxsResponse(678-680)
🪛 LanguageTool
docs/docs/learn/advanced/00-baseapp.md
[style] ~435-~435: Consider a shorter alternative to avoid wordiness.
Context: ...tomy.md#initchainer) of the application in order to initialize the main state of the applic...
(IN_ORDER_TO_PREMIUM)
docs/docs/building-modules/10-autocli.md
[style] ~20-~20: This phrase is redundant (‘I’ stands for ‘interface’). Use simply “CLI”.
Context: ...s. This means that you can easily add a CLI interface to your application without having to m...
(ACRONYM_TAUTOLOGY)
[uncategorized] ~27-~27: Possible missing preposition found.
Context: ....AppModuleinterface. 2. Configure how behaveautocli` command generation, by implem...
(AI_HYDRA_LEO_MISSING_TO)
[uncategorized] ~28-~28: This verb does not appear to agree with the subject. Consider using a different form.
Context: ... Use the autocli.AppOptions struct to specifies the modules you defined. If you are usi...
(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
[uncategorized] ~104-~104: Possible missing comma found.
Context: ...is defined in the appmodule.AppModule implementation located in the x/gov/autocli.go file....
(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~153-~153: This phrase is redundant (‘I’ stands for ‘interfaces’). Use simply “CLIs”.
Context: ...autocli is a powerful tool for adding CLI interfaces to your Cosmos SDK-based applications. ...
(ACRONYM_TAUTOLOGY)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: tests (00)
- GitHub Check: Analyze
- GitHub Check: Gosec
🔇 Additional comments (178)
orm/go.mod (2)
3-6: Upgrade Go version and toolchain
The module directives have been bumped to Go 1.23.0 / toolchain go1.23.5. This aligns with the broader SDK updates. Ensure that your CI/CD environments and developer machines are updated to support Go 1.23.x.
11-23: Update direct dependencies
Direct requirements have been upgraded, includinggithub.com/cosmos/cosmos-db,github.com/stretchr/testify, andgoogle.golang.org/protobuf. These version bumps look appropriate—please run full integration tests to confirm compatibility.go.mod (2)
1-4: Upgrade Go toolchain directives
The project now targets Go 1.23.5 with toolchain go1.23.8. Confirm that your local development environments and CI runners are updated accordingly to prevent build failures.
7-71: Bump direct dependencies including CometBFT v1 API
Multiple direct dependencies have been upgraded, notably the addition ofgithub.com/cometbft/cometbft/api v1.0.0alongside updates to core Cosmos SDK modules. Ensure all code imports and protobuf-generated files reference the new CometBFT v1 API types and that no legacy Tendermint types remain. Run full test suite to verify end-to-end compatibility.baseapp/params.go (1)
6-6: Update cmtproto import path to CometBFT v1 API
Import changed from legacy Tendermint protobuf togithub.com/cometbft/cometbft/api/cometbft/types/v1. Ensure thatConsensusParamsand related types in this package match the updated definitions and that no references to old paths remain.client/grpc/cmtservice/block.go (1)
6-6: Import updated to CometBFT v1 API
Thecmtprotoalias now points togithub.com/cometbft/cometbft/api/cometbft/types/v1, matching the new CometBFT v1 protobuf definitions. This change is consistent with the migration and correctly scopes theBlockandBlockIDtypes.baseapp/utils_test.go (1)
16-16: Use new CometBFT v1 protobuf package in tests
The import forcmtprotohas been updated to the CometBFT v1 API path, ensuring the test utilities reference the correctConsensusParamstype.baseapp/testutil/mock/mocks.go (1)
11-11: Align crypto import with CometBFT v1 API
The mock package now importsgithub.com/cometbft/cometbft/api/cometbft/crypto/v1under thecryptoalias, matching the updated protobuf definitions without altering the mock interfaces.baseapp/params_legacy.go (1)
41-41: Switch legacy params to CometBFT v1 types
The legacy params file now imports the CometBFT v1 protobuf package for consensus types, ensuring thatBlockParams,EvidenceParams,ValidatorParams, andConsensusParamsuse the correct v1 API definitions.crypto/codec/cmt.go (1)
4-4: Update public key proto import to CometBFT v1
The aliascmtprotocryptonow referencesgithub.com/cometbft/cometbft/api/cometbft/crypto/v1, aligning the public key conversion routines with the new v1 protobuf schema.client/rpc/block.go (1)
9-9: Import path updated to use CometBFT v1 APIThis change correctly updates the import path from the deprecated Tendermint protobuf package to the new CometBFT v1 API package, consistent with the overall migration to CometBFT v1.
client/grpc_query.go (1)
86-90: ABCI type updated from RequestQuery to QueryRequestThis change correctly migrates from the deprecated Tendermint
abci.RequestQuerytype to the current CometBFTabci.QueryRequesttype while maintaining the same field structure. This aligns with the broader ABCI type migration in the SDK.client/rpc/rpc_test.go (1)
97-102: Test updated to use QueryRequest instead of RequestQueryThe test has been appropriately updated to use the new
abci.QueryRequesttype, maintaining consistency with the production code and ensuring the tests remain valid with the CometBFT v1 API changes.client/grpc/cmtservice/util.go (1)
4-4: Import path updated to use CometBFT v1 APIThe import path for
cmtprototypeshas been correctly updated to use the new CometBFT v1 API package, ensuring compatibility with other updated components in the codebase.client/grpc_query_test.go (2)
86-91: LGTM: Successfully migrated to CometBFT v1 request type.The change from
RequestInitChaintoInitChainRequestaligns with the CometBFT v1 API conventions while maintaining identical functionality.
93-97: LGTM: Successfully migrated to CometBFT v1 request type.The change from
RequestFinalizeBlocktoFinalizeBlockRequestcorrectly follows the CometBFT v1 API naming pattern.baseapp/msg_service_router_test.go (2)
153-154: LGTM: Successfully migrated to CometBFT v1 request type.The change from
RequestFinalizeBlocktoFinalizeBlockRequestaligns with the CometBFT v1 API naming convention.
199-201: LGTM: Successfully migrated to CometBFT v1 request type.The change from
RequestFinalizeBlocktoFinalizeBlockRequestcorrectly follows the CometBFT v1 API naming pattern, maintaining the same functionality while updating the type.baseapp/grpcrouter_helpers.go (1)
48-48: LGTM: Successfully migrated to CometBFT v1 query request type.The change from
RequestQuerytoQueryRequestcorrectly follows the CometBFT v1 API naming pattern. This update maintains identical functionality while aligning with the new conventions.api/go.mod (1)
6-6: LGTM: Required dependencies for CometBFT v1 integration.The added CometBFT protobuf package and updated dependency versions are necessary to support the migration to CometBFT v1 API types. These changes align with the PR objective of integrating CometBFT v1.
Also applies to: 11-11, 15-15
baseapp/options.go (1)
353-360: Setter method for customizing CheckTx handling looks goodThis new method follows the established pattern for BaseApp setter methods in the codebase - checking if the app is sealed before allowing changes and panicking with a clear message if it is. This provides a way for applications to customize the CheckTx processing logic, which aligns with the CometBFT v1 integration effort.
baseapp/block_gas_test.go (2)
118-122: Successfully updated ABCI request typeThe change from
RequestInitChaintoInitChainRequestcorrectly aligns with the CometBFT v1 API naming conventions. This type replacement correctly maintains the same parameter structure and functionality.
158-159: Successfully updated ABCI request typeThe change from
RequestFinalizeBlocktoFinalizeBlockRequestcorrectly aligns with the CometBFT v1 API naming conventions. The test logic remains unchanged, and the parameters passed to the function maintain the same functionality.client/utils.go (1)
81-81: Simplified RPC client initializationRemoving the explicit
/websocketpath parameter simplifies the client initialization while ensuring compatibility with CometBFT v1. This change correctly relies on the default endpoint configuration in the newer CometBFT RPC client implementation.docs/docs/learn/advanced/00-baseapp.md (1)
207-211: Documentation updated to reflect new type namesThe documentation has been properly updated to use
InitChainRequestinstead of the deprecatedRequestInitChaintype, ensuring consistency with the actual code implementation.client/rpc/tx.go (3)
26-51: Function name updated to match CometBFT v1 naming conventionsThe function has been renamed from
newTxResponseCheckTxtonewTxCheckTxResponse, which aligns with the CometBFT v1 naming pattern where the response type appears at the end of the function name. The implementation remains unchanged.
85-87: Updated function call to match renamed functionThe function call has been updated to use the renamed function
newTxCheckTxResponse, maintaining consistency with the function name change above.
122-123: Simplified RPC client initialization by removing explicit websocket pathThe explicit
"/websocket"path argument has been removed from therpchttp.Newcall, now relying on the default path. This change aligns with the CometBFT v1 client API which now handles the default path internally.baseapp/info.go (3)
147-149: Updated embedded type to CometBFT v1 ABCI typeThe embedded field type has been changed from
*abci.RequestPrepareProposalto*abci.PrepareProposalRequest, reflecting the migration to the newer CometBFT v1 API naming convention.
161-163: Updated field access path for ProposerAddressThe field access has been updated to use the new field path
r.PrepareProposalRequest.ProposerAddressconsistent with the type change above.
165-167: Updated field access and name for LastCommitThe field access has been updated from using
LastCommittoLocalLastCommit, reflecting both the type change and a field name change in the CometBFT v1 API.baseapp/test_helpers.go (5)
3-10: Updated import path to use new CometBFT v1 protobuf typesThe import path for the
cmtprotopackage has been updated from the legacy Tendermint path to the new CometBFT v1 API path, consistent with the overall migration to CometBFT v1.
22-23: Added transaction parameter to runTx call in SimCheckThe
runTxmethod call now includes the decoded transaction as a third parameter, which avoids redundant decoding during transaction processing. This is an optimization aligned with updatedrunTxmethod signature inBaseApp.
28-29: Passing nil transaction to runTx in SimulateIn the
Simulatemethod,nilis passed as the decoded transaction since only raw transaction bytes are available. This maintains compatibility with the updatedrunTxsignature while preserving the original behavior.
39-40: Added transaction parameter to runTx call in SimDeliverSimilar to the change in
SimCheck, the decoded transaction is now passed as a third parameter torunTx, avoiding redundant decoding.
50-51: Added transaction parameter to runTx call in SimTxFinalizeBlockThe decoded transaction is now passed as a third parameter to
runTx, consistent with the pattern used in other simulation methods.docs/docs/learn/advanced/15-upgrade.md (1)
106-110: Updated InitChainer signature to use CometBFT v1 typeThe method signature in the documentation has been updated to use
abci.InitChainRequestinstead of the deprecatedabci.RequestInitChain, reflecting the migration to CometBFT v1 API types. The example also now includes a call toSetModuleVersionMapwhich is important for proper upgrade tracking.baseapp/oe/optimistic_execution_test.go (2)
14-14: Function signature updated correctly to new CometBFT v1 API typesThe function signature has been properly updated to use the new CometBFT v1 ABCI types
*abci.FinalizeBlockRequestand*abci.FinalizeBlockResponseinstead of the deprecated Tendermint types.
21-21: Parameter type correctly updated to CometBFT v1 APIThe parameter type for
oe.Execute()has been properly updated to use the newabci.ProcessProposalRequesttype, which is consistent with the migration to CometBFT v1.baseapp/baseapp_test.go (4)
13-13: Import path updated to use new CometBFT v1 APIThe import path has been correctly updated from the deprecated Tendermint proto path to the new CometBFT v1 API path.
101-102: ABCI request types consistently updated to CometBFT v1 APIAll instances of the deprecated
RequestFinalizeBlocktype have been systematically replaced with the newFinalizeBlockRequesttype from the CometBFT v1 API. The function calls and error handling remain unchanged.Also applies to: 106-107, 130-133, 165-169, 227-228, 253-257, 260-264, 283-286, 369-373, 418-422
216-219: InitChain request type updated to CometBFT v1 APIAll instances of the deprecated
RequestInitChaintype have been systematically replaced with the newInitChainRequesttype from the CometBFT v1 API, maintaining consistent behavior.Also applies to: 527-530, 567-570, 721-724, 801-802
389-392: Query request type updated to CometBFT v1 APIThe Query request type has been properly updated from
RequestQuerytoQueryRequestwhile maintaining the same function behavior and error handling.Also applies to: 398-401
baseapp/grpcrouter.go (2)
53-53: GRPCQueryHandler type alias updated to CometBFT v1 APIThe type alias has been correctly updated to use the new CometBFT v1 ABCI types
*abci.QueryRequestand*abci.QueryResponse.
106-128: Query handler implementation updated to use new CometBFT v1 typesThe implementation of the ABCI query handler has been properly updated to use the new query request and response types while maintaining the same field access patterns and logic.
client/grpc/cmtservice/service.go (2)
28-28: abciQueryFn type alias updated to CometBFT v1 APIThe type alias for the ABCI query function has been correctly updated to use the new CometBFT v1 ABCI types.
249-253: ABCIQuery method updated to use new conversion methodsThe method calls have been updated to use the new conversion methods
ToABCIQueryRequest()andFromABCIQueryResponse()that are compatible with the CometBFT v1 API.baseapp/abci_utils_test.go (5)
8-10: Update imports for new CometBFT v1 API paths
The imports have been updated to use the new CometBFT protobuf packages (api/cometbft/...), aligning the test code with the migrated ABCI types.
496-499: Align test struct withPrepareProposalRequest
The test case struct’sreqfield is now declared as*abci.PrepareProposalRequest, matching the updated handler signature.
503-503: ConstructPrepareProposalRequestinstances in NoOp tests
Each NoOp test case now instantiates&abci.PrepareProposalRequest{…}and, where needed, setsMaxTxBytesand usesctx.WithConsensusParams(cmtproto.ConsensusParams{…}). This correctly replaces the deprecatedRequestPrepareProposal.Also applies to: 515-515, 523-523, 535-535
615-619: Align priority nonce test struct with new request type
In the PriorityNonce tests, thereqfield is updated to*abci.PrepareProposalRequest, consistent with the new ABCI API.
626-626: ConstructPrepareProposalRequestinstances in PriorityNonce tests
Each priority nonce test case now initializesreqas&abci.PrepareProposalRequest{MaxTxBytes: …}, reflecting the migration from the old Tendermint request type.Also applies to: 633-633, 642-642, 651-651
client/grpc/cmtservice/types.go (2)
7-9: Rename conversion method toToABCIQueryRequest
The receiver method onABCIQueryRequesthas been renamed toToABCIQueryRequest()returning*abci.QueryRequest, aligning with CometBFT v1’s ABCI types.
18-21: Rename conversion function toFromABCIQueryResponse
The standalone converter now accepts*abci.QueryResponseand returns*ABCIQueryResponse, matching the updated ABCI protobuf naming conventions.api/cosmos/consensus/v1/query.pulsar.go (7)
5-5: Update import path to CometBFT v1 consensus types
The import aliasv1points to the newbuf.build/.../cometbft/types/v1package, ensuring the generated code uses the correct ConsensusParams definitions.
859-859: Usev1.ConsensusParamsinQueryParamsResponsestruct
TheParamsfield is updated to*v1.ConsensusParams, replacing the old Tendermint type and matching the new protobuf schema.
529-531: Type-assertParamsin fast reflection Set method
The setter now correctly asserts the incoming message to*v1.ConsensusParams, maintaining type safety in the reflection-based code.
553-554: InitializeParamsin fast reflection Mutable method
Lazily allocatingx.Params = new(v1.ConsensusParams)ensures a non-nil message when accessed via reflection.
571-572: Allocate newConsensusParamsin fast reflection NewField
Creating a freshv1.ConsensusParamsinstance inNewFieldaligns with the protobuf runtime’s expectations for message fields.
882-887: AddGetParamsaccessor for nil-safe retrieval
The newGetParams()method safely returns theParamsfield ornil, simplifying client code and matching protobuf conventions.
944-947: Update Go type mappings to includev1.ConsensusParams
ThegoTypesslice now lists(*v1.ConsensusParams)(nil), ensuring correct descriptor-to-Go-type associations in the generated file.docs/docs/build/abci/04-checktx.md (1)
1-50: New documentation looks good and accurately explains the CheckTx processThis documentation clearly explains the CheckTx process, including how it's triggered by CometBFT, its validation flow, and how to use the new
CheckTxHandlerfeature. The Mermaid diagram effectively illustrates the interaction between components.client/query.go (5)
51-57: Updated function signature to use new CometBFT typesThe function signature has been correctly updated to use the new CometBFT types:
abci.QueryRequestinstead ofabci.RequestQueryandabci.QueryResponseinstead ofabci.ResponseQuery.
79-83: Updated function signature and return type to use new CometBFT typesThe function signature has been correctly updated to use the new CometBFT types.
104-105: Updated error handling to use new CometBFT typesThe error handling code has been correctly updated to use the new CometBFT types.
115-126: Updated function signature to use new CometBFT typesThe
sdkErrorToGRPCErrorfunction signature has been correctly updated to use the new CometBFT types.
132-142: Updated query request construction to use new CometBFT typesThe query request construction has been correctly updated to use the new CometBFT types.
baseapp/snapshot_test.go (8)
26-40: Updated snapshot test to use new CometBFT typesThe test code has been correctly updated to use the new CometBFT ABCI types for snapshot operations.
125-136: Updated ListSnapshots request and response typesThe test code has been correctly updated to use the new CometBFT ABCI types for
ListSnapshots.
153-166: Updated Query request typesThe test code has been correctly updated to use the new CometBFT ABCI types for queries.
198-210: Updated LoadSnapshotChunk request and response typesThe test code has been correctly updated to use the new CometBFT ABCI types for
LoadSnapshotChunk.
231-246: Updated enum types for snapshot resultsThe test code has been correctly updated to use the new CometBFT enum types for snapshot operation results.
257-276: Updated OfferSnapshot request and response typesThe test code has been correctly updated to use the new CometBFT ABCI types for
OfferSnapshot.
298-310: Updated ListSnapshots and OfferSnapshot typesThe test code has been correctly updated to use the new CometBFT ABCI types.
313-343: Updated ApplySnapshotChunk and LoadSnapshotChunk typesThe test code has been correctly updated to use the new CometBFT ABCI types for chunk operations.
baseapp/streaming_test.go (7)
9-10: Updated import to use new CometBFT proto packageThe import has been correctly updated to use the new CometBFT API v1 proto package.
32-39: Updated ABCIListener interface methods to use new CometBFT typesThe
MockABCIListenerimplementation has been correctly updated to use the new CometBFT ABCI types forFinalizeBlockandCommit.
54-58: Updated InitChain request typeThe test code has been correctly updated to use the new CometBFT ABCI types for
InitChain.
72-73: Updated FinalizeBlock request typeThe test code has been correctly updated to use the new CometBFT ABCI types for
FinalizeBlock.
97-105: Updated FinalizeBlock request type and response handlingThe test code has been correctly updated to use the new CometBFT ABCI types for
FinalizeBlock.
122-124: Updated InitChain request typeThe test code has been correctly updated to use the new CometBFT ABCI types for
InitChain.
136-137: Updated FinalizeBlock request typeThe test code has been correctly updated to use the new CometBFT ABCI types for
FinalizeBlock.api/cosmos/staking/v1beta1/staking.pulsar.go (18)
5-6: Import CometBFT v1 modules
The new aliasesv1andv11correctly reference the updated CometBFTtypes/v1andabci/v1protobuf packages.
249-251: Update reflection Set to use new Header type
TheSetmethod correctly casts incoming messages to*v1.Header, aligning with the CometBFT v1 API.
275-278: Lazy-initialize Header with new CometBFT v1 type
Ensuresx.Headeris non-nil and of typev1.Headerbefore use.
299-301: NewField returns new CometBFT v1 Header message
Constructs a freshv1.Headerinstance for reflection, matching the updated type.
521-523: Lazy-initialize Header during unmarshal
Assigns&v1.Header{}ifx.Headeris nil, ensuring the unmarshal destination uses the correct type.
12190-12192: List type for ValidatorUpdates updated
The_ValidatorUpdates_1_listnow holds[]*v11.ValidatorUpdate, pointing to the new CometBFT v1 type.
12205-12221: Reflection Set/Append now uses CometBFT v1 ValidatorUpdate
All occurrences inSet,Append, andAppendMutablecorrectly unwrap to*v11.ValidatorUpdate, matching the new import alias.
12231-12233: Reflection NewElement uses correct CometBFT v1 type
NewElementnow instantiatesv11.ValidatorUpdate, ensuring all reflection-generated messages use the updated type.
12423-12425: fastReflection_ValidatorUpdates lazy-initialization updated
Initializesx.Updatesas[]*v11.ValidatorUpdate, conforming to the new API.
12441-12444: fastReflection_ValidatorUpdates.NewField returns new ValidatorUpdate list
Creates a list tied to[]*v11.ValidatorUpdate, reflecting the updated import.
12642-12644: Unmarshal logic appends new CometBFT v1 ValidatorUpdate
Ensures each element appended during binary unmarshalling is of type*v11.ValidatorUpdate.
12814-12816: HistoricalInfo struct now references v1.Header
TheHeaderfield uses*v1.Headerfrom the CometBFT v1 package, replacing the legacy Tendermint type.
12838-12840: Add GetHeader accessor returning new Header type
ProvidesGetHeader()to expose*v1.Header, matching the updated message definition.
14003-14004: *ValidatorUpdates struct now uses []v11.ValidatorUpdate
Replaces the old validator update slice with the CometBFT v1ValidatorUpdatetype.
14026-14028: Add GetUpdates accessor for ValidatorUpdates
ExposesGetUpdates()returning[]*v11.ValidatorUpdate, consistent with the new field.
14051-14055: Raw descriptor byte updates
Generated binary descriptor bytes have changed to include new import paths; no manual action required.
14467-14473: Update proto dependency indexes for CometBFT v1
Entries for*v1.Headerand*v11.ValidatorUpdatecorrectly align with their new dependency indexes.
14495-14497: Dependency index for ValidatorUpdates.updates updated
Maps theupdatesfield tocometbft.abci.v1.ValidatorUpdatein the dependency slice.baseapp/oe/optimistic_execution.go (2)
18-19: Type alias update looks correct.The change to
FinalizeBlockFuncaligns with CometBFT v1 message names and keeps
the signature consistent with upstream ABCI.
28-29: Struct field rename is consistent with new ABCI types.Good catch updating both
requestandresponsepointers to the new
FinalizeBlock*types.api/cosmos/staking/v1beta1/genesis.pulsar.go (3)
273-318: Generated list wrapper looks fine but remember downstream tooling.The new
_GenesisState_9_listcorrectly implementsprotoreflect.Listfor the
AllowedDelegationTransferReceiversstring slice.Please ensure:
- All protobuf/gogo-based clients are regenerated after this field addition.
- Genesis import/export logic (
x/staking/keeper/export.go, migrations, etc.)
handles the new field to avoid state-machine divergence.
459-465: Reflection path added – confirm JSON/state migrations.The reflection code now serialises/deserialises
allowed_delegation_transfer_receivers(field 9).
Double-check migration scripts and any JSON → proto conversions so this slice
is preserved during upgrades.
856-861: Size accounting updated – no issues spotted.Loop correctly iterates over the new string slice when computing encoded
message size.api/cosmos/store/v1beta1/listening.pulsar.go (9)
5-5: Update import to CometBFT v1 ABCI types
Replacing legacy Tendermint ABCI import with the new CometBFT v1 package is correct and consistent with the migration.
807-814: UpdateSetmethod to use CometBFT v1 message types
TheSetbranch now correctly type-asserts to*v1.CommitResponse,*v1.FinalizeBlockRequest, and*v1.FinalizeBlockResponse. This aligns with the updated protobuf definitions.
835-842: Initialize new fields using CometBFT v1 message constructors
TheMutablemethod now lazily allocatesv1.CommitResponse,v1.FinalizeBlockRequest, andv1.FinalizeBlockResponsewhen needed. Correct and thread-unsafe as expected for reflected code.
861-870: Construct new default values for CometBFT v1 fields inNewField
TheNewFieldmethod returns fresh mutable messages of the correct v1 types, ensuring compatibility with the new API.
1299-1301: ExtendBlockMetadatastruct with CometBFT v1 fields
The new fields (ResponseCommit,RequestFinalizeBlock,ResponseFinalizeBlock) are correctly typed for CometBFT v1 messages. Check the TODO about renumbering in the proto if necessary, but the integration here is accurate.
1324-1343: Update accessor methods to return CometBFT v1 message pointers
TheGetResponseCommit,GetRequestFinalizeBlock, andGetResponseFinalizeBlockmethods now return pointers to the correct v1 message types.
1351-1353: Update raw descriptor import path to CometBFT v1
The raw GZIP descriptor now referencescometbft/abci/v1/types.protoinstead of the legacy Tendermint path, which is correct for the migration.
1410-1415: RefreshgoTypesto include CometBFT v1 message types
Entries for*v1.CommitResponse,*v1.FinalizeBlockRequest, and*v1.FinalizeBlockResponsereplace the old ABCI types, matching the import alias and the file dependencies.
1417-1419: Update dependency indexes for new CometBFT v1 fields
The field-to-type mappings indepIdxsnow correctly point to the new v1 message indices.api/cosmos/store/streaming/abci/grpc.pulsar.go (15)
5-5: Import CometBFT v1 ABCI package
Switching the import aliasv1to point atbuf.build/.../cometbft/abci/v1aligns with migrating to CometBFT v1.
189-191: ReflectSetmethod updates forListenFinalizeBlockRequest
TheSetcases now correctly cast to*v1.FinalizeBlockRequestand*v1.FinalizeBlockResponse, matching the new ABCI v1 types.
214-219: Lazy initialization inMutableforListenFinalizeBlockRequest
Allocating newv1.FinalizeBlockRequestandv1.FinalizeBlockResponseinstances inMutableis correct for reflecting the new message types.
236-241:NewFieldcreation forListenFinalizeBlockRequestfields
Returning freshv1.FinalizeBlockRequestandv1.FinalizeBlockResponseinNewFieldmatches the updated proto definitions.
1883-1885: UpdateListenFinalizeBlockRequeststruct fields
The struct now embeds pointers tov1.FinalizeBlockRequestandv1.FinalizeBlockResponse, replacing deprecated types.
1907-1915: Adjust getter methods forListenFinalizeBlockRequest
GetReqandGetResnow return the correct v1 message pointers, ensuring clients receive the new ABCI v1 types.
1955-1957: ExtendListenCommitRequestwith CometBFT v1 response
AddingRes *v1.CommitResponseensures the Commit listener uses the new CommitResponse type.
1987-1992: Add getter for newResfield inListenCommitRequest
TheGetResmethod correctly returns the*v1.CommitResponse, aligning with the updated struct.
1129-1131: Update reflectionSetforListenCommitRequest
The reflection-basedSetnow type-asserts to*v1.CommitResponsefor theresfield, matching the transition to ABCI v1.
1155-1158: ReflectMutablechanges forListenCommitRequest.res
Allocating a newv1.CommitResponsein theMutableimplementation is correct for the v1 migration.
1184-1186:NewFieldimplementation forListenCommitRequest.res
Creating a newv1.CommitResponsemessage inNewFieldaligns with the updated proto schema.
1431-1434: Handle unmarshal initialization forresinListenCommitRequest
TheUnmarshalmethod correctly initializesx.Resas&v1.CommitResponse{}before unmarshaling the incoming data.
2035-2037: Update raw proto descriptor to reference CometBFT v1
The raw GZIP descriptor now importscometbft/abci/v1/types.proto, ensuring the metadata aligns with the v1 package.
2117-2120: RefreshgoTypesfor streaming service
goTypesnow includes*v1.FinalizeBlockRequest,*v1.FinalizeBlockResponse, and*v1.CommitResponse, matching the upgraded API.
2123-2126: AdjustdepIdxsentries for streaming RPC types
Dependency indexes now map the request/response fields to the correct v1 message types (FinalizeBlockRequest,FinalizeBlockResponse,CommitResponse).baseapp/abci_test.go (4)
18-19: Well-structured import updates for CometBFT v1 integration.The import updates correctly replace Tendermint proto imports with their CometBFT v1 API equivalents, following the naming convention for the new API.
49-53: Consistent application of CometBFT v1 naming conventions.The code correctly implements the CometBFT v1 request type naming convention (changing from
RequestXxxtoXxxRequest). This update is systematically applied throughout the entire file without altering the test logic.
299-303: Status constants properly updated to CometBFT v1 equivalents.The vote extension verification status constants have been updated to use the new CometBFT v1 constants (
VERIFY_VOTE_EXTENSION_STATUS_REJECTandVERIFY_VOTE_EXTENSION_STATUS_ACCEPT), maintaining the same logical behavior while adapting to the new API.
580-583: CheckTx type constants updated for CometBFT v1 compatibility.The
CheckTxRequesttype and associated constants (CHECK_TX_TYPE_CHECKandCHECK_TX_TYPE_RECHECKelsewhere in the file) have been properly updated to align with CometBFT v1's API conventions. These changes support the newcheckTxHandlerfunctionality added to BaseApp.baseapp/baseapp.go (5)
13-13: Import path correctly updated for CometBFT v1.The import has been properly updated to use the new CometBFT v1 API path, consistent with the migration goals of this PR.
95-95: Valuable addition of customizable CheckTx handling.Adding the
checkTxHandlerfield extends BaseApp's capabilities by allowing applications to provide custom transaction validation logic during the CheckTx process. This is a significant functional enhancement that gives developers more flexibility when building on the Cosmos SDK.
611-611: Method signatures consistently updated for CometBFT v1 compatibility.The method signatures for
validateFinalizeBlockHeight,preBlock, andbeginBlockhave been systematically updated to use the new CometBFT v1 typeFinalizeBlockRequest, maintaining API consistency throughout the codebase.Also applies to: 734-734, 756-756
867-869: Valuable performance optimization to avoid redundant transaction decoding.The
runTxmethod now accepts an optional pre-decoded transaction, allowing callers to pass an already decoded transaction and avoid redundant decoding operations. This optimization can reduce CPU usage, especially in hot paths like proposal verification.
1177-1177: Optimization consistently applied across proposal verification methods.The methods
PrepareProposalVerifyTxandProcessProposalVerifyTxhave been correctly updated to pass the decoded transaction torunTx, taking full advantage of the optimization to avoid redundant decoding. This ensures consistent performance improvements across proposal verification operations.Also applies to: 1196-1196
api/cosmos/app/runtime/v1alpha1/module.pulsar.go (3)
389-434: Addition ofPreBlockerslist wrapper looks correct and consistentThe boiler-plate list implementation for
_Module_10_listmirrors the pattern used for the other repeated‐string wrappers (e.g._Module_2_list,_Module_3_list, …).
•Len,Get,Set,Append,NewElement,IsValid, etc. are implemented identically.
• The panic message inAppendMutableis accurate because the element kind is scalar (string).No issues spotted.
583-590:PreBlockerscorrectly wired into fast-reflectionRangetraversalThe new block cleanly mirrors the existing logic for the other repeated fields and references the right field descriptor (
fd_Module_pre_blockers).
2102-2106: Struct field registration matches proto tag 10 – please ensure runtime usageThe
Modulestruct now exposes:PreBlockers []string `protobuf:"bytes,10,rep,name=pre_blockers,json=preBlockers,proto3"`Everything compiles, but double-check that downstream runtime code (e.g. module manager / router) actually consumes
PreBlockers; otherwise the field will remain unused.If you’d like, I can generate a quick repository scan script to verify that the new accessor
GetPreBlockers()is referenced.api/cosmos/autocli/v1/options.pulsar.go (1)
671-678: New field descriptors wired-in correctly
enhance_custom_command(bool, tag = 4) andshort(string, tag = 5) are registered alongside existing descriptors; no collisions observed.api/cosmos/base/tendermint/v1beta1/query.pulsar.go (17)
5-6: Update import paths for CometBFT v1 packages
The new aliasesv11andv1correctly point to the updated CometBFTp2p/v1andtypes/v1protobuf packages.
3369-3371: Applyv1alias for BlockID and Block in Set
TheSetmethod now correctly casts messages to*v1.BlockIDand*v1.Blockusing the newv1alias.
3396-3401: InstantiateBlockIdandBlockwhen nil in Get
Initializingx.BlockIdandx.Blockwithnew(v1.BlockID)andnew(v1.Block)prevents nil-pointer dereferences during reflection.
3423-3426: NewField now creates correct CometBFT types
TheNewFieldmethod instantiatesv1.BlockIDandv1.Blockas expected, aligning with the updated type definitions.
4318-4320: Use updatedv1alias in LatestBlockResponse.Set
FieldsBlockIdandBlockare now set viav1.BlockIDandv1.Block, correctly referencing CometBFT v1 types.
4345-4350: Instantiate LatestBlockResponse fields when nil
TheGetlogic usesnew(v1.BlockID)andnew(v1.Block)to prevent nil-pointer issues, consistent with the migration.
4372-4375:NewFieldfor LatestBlockResponse uses correct v1 types
NewFieldnow creates instances ofv1.BlockIDandv1.Block, aligning with theSetandGetimplementations.
6018-6018: Usev11alias for DefaultNodeInfo in Set
TheSetmethod now casts to*v11.DefaultNodeInfo, correctly referencing the CometBFT p2p/v1 package.
6043-6043: Initialize DefaultNodeInfo when nil
Usingnew(v11.DefaultNodeInfo)here prevents nil-pointer dereferences during reflection.
6065-6065: Instantiate DefaultNodeInfo in NewField
TheNewFieldmethod correctly allocates av11.DefaultNodeInfoinstance.
6283-6283: Initialize DefaultNodeInfo pointer for unmarshalling
The&v11.DefaultNodeInfo{}allocation ensures the field is non-nil beforeUnmarshal.
10690-10692: Update struct tags to use CometBFT v1 types
FieldsBlockIdandBlocknow reference*v1.BlockIDand*v1.Block, matching the new imports.
10717-10727: Generated getters reference new v1 types
GetBlockId()andGetBlock()return pointers tov1.BlockIDandv1.Block, as intended after the migration.
10771-10773: Update LatestBlockResponse struct to CometBFT types
BlockIdandBlockfields now use*v1.BlockIDand*v1.Block, consistent with GetBlockByHeightResponse.
10799-10808: Generated getters reference new v1 types (LatestBlockResponse)
GetBlockId()andGetBlock()correctly return the updated CometBFT v1 types.
10915-10916: Update GetNodeInfoResponse struct to usev11DefaultNodeInfo
DefaultNodeInfofield now references*v11.DefaultNodeInfo, reflecting the p2p/v1 migration.
10939-10942: Generated getter returns the newv11type
GetDefaultNodeInfo()now returns*v11.DefaultNodeInfo, consistent with the updated struct.api/cosmos/consensus/v1/tx.pulsar.go (1)
4-6: Confirm the new CometBFT v1 import path is resolvable ingo.mod.The generated file now imports:
v1 "buf.build/gen/go/cometbft/cometbft/protocolbuffers/go/cometbft/types/v1"If this artefact repository is missing from
go.mod(or replaced with a localreplacedirective), the build will fail downstream.
Please rungo mod tidyand ensure a versioned entry similar to:buf.build/gen/go/cometbft/cometbft vX.Y.Zis present, or switch to the canonical public import path if the Buf-build mirror is not intended for production.
api/cosmos/base/abci/v1beta1/abci.pulsar.go (16)
5-6: Migration from Tendermint to CometBFT completed successfully.The imports have been correctly updated to reference the new CometBFT protobuf packages instead of the deprecated Tendermint packages. This change is consistent with the PR objective of integrating CometBFT v1.
73-74: Import and type references updated correctly for TxResponse fields.All references to Tendermint Event types have been properly migrated to use the CometBFT v1 Event types in the
_TxResponse_13_listimplementation. This ensures consistency with the CometBFT v1 integration throughout the codebase.Also applies to: 90-91, 95-97, 100-102, 113-115
526-528: Event type correctly updated in Mutable implementation.The Events initialization is properly updated to use the CometBFT v1 Event type instead of the Tendermint Event type, maintaining consistency with the new API.
591-592: NewField method properly updated for CometBFT Event type.The method now returns a list of CometBFT v1 Event objects instead of Tendermint Event objects, ensuring consistency with the overall migration.
1267-1268: Event instantiation correctly updated in unmarshal function.The unmarshal function now correctly appends a new CometBFT v1 Event to the Events slice, completing the migration from Tendermint to CometBFT.
3407-3410: Result Event list implementation updated to use CometBFT types.The
_Result_3_listimplementation has been properly updated to use CometBFT v1 Event types, ensuring compatibility with the new API structure while maintaining the same functionality.Also applies to: 3425-3427, 3432-3433, 3437-3440, 3449-3451
3750-3751: Event initialization updated in Result's Mutable method.The Events initialization now correctly uses CometBFT v1 Event types, ensuring consistency with the rest of the migration.
3782-3783: NewField implementation properly updated for Result.The method now returns a list of CometBFT v1 Event objects, maintaining compatibility with the rest of the codebase.
4095-4098: Result unmarshal function properly updated.The unmarshal function now correctly appends a new CometBFT v1 Event to the Events slice when deserializing Result objects.
6535-6584: SearchBlocksResult list implementation updated to use CometBFT types.The
_SearchBlocksResult_6_listimplementation has been correctly migrated to use CometBFT v1 Block types instead of Tendermint Block types, ensuring consistency with the CometBFT v1 API.
6856-6857: Block initialization updated in SearchBlocksResult's Mutable method.The Blocks initialization now correctly uses CometBFT v1 Block types, ensuring consistency with the rest of the migration.
6894-6895: NewField implementation properly updated for SearchBlocksResult.The method now returns a list of CometBFT v1 Block objects, maintaining compatibility with the rest of the codebase.
7229-7232: SearchBlocksResult unmarshal function properly updated.The unmarshal function now correctly appends new CometBFT v1 Block objects to the Blocks slice when deserializing SearchBlocksResult objects.
8015-8021: Protobuf imports successfully migrated to CometBFT.The protobuf imports have been correctly updated to reference CometBFT packages instead of Tendermint packages. This is a critical change for ensuring compatibility with the CometBFT v1 API.
8048-8051: Event type references in protobuf correctly updated.The protobuf field definitions for Event types have been properly updated to reference the CometBFT v1 Event type, and the go type mappings have been updated accordingly.
Also applies to: 8182-8183
8188-8191: Protocol buffer dependency indexes updated properly.The dependency indexes for CometBFT Event types have been correctly updated in the protobuf initialization code, ensuring proper serialization and deserialization.
api/cosmos/base/tendermint/v1beta1/types.pulsar.go (1)
1-10: Generated file – review skippedThe file is auto-generated (
protoc-gen-go-pulsar). Manual edits will be
overwritten, so no review comments are necessary.baseapp/abci.go (1)
13-15:Details
❌ Incorrect review comment
Check the correctness of the new
cmtprotoimport pathThe path
github.com/cometbft/cometbft/api/cometbft/types/v1
contains the segmentcometbfttwice. Up-stream CometBFT v1 modules usually live under either
github.com/cometbft/cometbft/api/types/v1, orgithub.com/cometbft/cometbft/proto/tendermint/types(legacy)If the duplicated segment is a typo the file will fail to compile after
go mod tidy.
🏁 Script executed:
#!/usr/bin/env bash # Verify whether the imported module really exists in the go.sum / mod cache grep -R --line-number "github.com/cometbft/cometbft/api/cometbft/types/v1" || trueLength of output: 10503
Confirm validity of
cmtprotoimport path
The path
github.com/cometbft/cometbft/api/cometbft/types/v1
matches the upstream CometBFT repo structure (theapi/cometbft/types/v1package) and is imported successfully across the codebase. No change is required.Likely an incorrect or invalid review comment.
| * [#19039](https://github.com/cosmos/cosmos-sdk/pull/19039) Add support for pubkey in autocli. | ||
| * [#20266](https://github.com/cosmos/cosmos-sdk/pull/20266) Ability to override the short description in AutoCLI-generated top-level commands. | ||
|
|
||
| ### Improvements |
There was a problem hiding this comment.
Remove duplicate changelog entry and add a grouping tag
Issue #20266 appears twice—once under Features and again under Improvements—and both entries lack a tag (e.g. (autocli)). Consolidate into a single entry under the correct stanza and prepend the appropriate tag for clarity.
| module cosmossdk.io/api | ||
|
|
||
| go 1.20 | ||
| go 1.23.5 |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify the Go version - potential future version specified.
The Go version is set to 1.23.5, which appears to be a future version not yet released (as of May 2024, Go 1.22.x is the latest release). This could lead to compatibility issues or build failures.
🏁 Script executed:
#!/bin/bash
# Check current Go release versions
curl -s https://go.dev/dl/?mode=json | head -n 20
echo "Currently specified version in go.mod:"
grep "^go " api/go.modLength of output: 665
🏁 Script executed:
#!/bin/bash
# List all Go release versions and check for 1.23.5
curl -s https://go.dev/dl/?mode=json \
| grep -Po '"version":\s*"\Kgo[0-9]+\.[0-9]+\.[0-9]+' \
| sort -u \
| tee /dev/stderr \
| grep -x "go1.23.5" || echo "go1.23.5 not found"Length of output: 282
Invalid Go version in api/go.mod
The go.mod file specifies Go version 1.23.5, which is not an official release (latest stable is 1.24.2). This will cause build failures in CI or local environments.
• File: api/go.mod Line 3
• Change
- go 1.23.5
+ go 1.24.2 # or whatever minimum supported version you need📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| go 1.23.5 | |
| -go 1.23.5 | |
| +go 1.24.2 # or whatever minimum supported version you need |
| // Create ChecktxHandler | ||
| checktxHandler := abci.NewCustomCheckTxHandler(...) | ||
| app.SetCheckTxHandler(checktxHandler) | ||
| ... | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Missing explanation of the custom handler parameters
The example shows using abci.NewCustomCheckTxHandler(...) but doesn't explain what parameters this function takes or how a developer would implement their own handler.
Consider adding a brief explanation of how to implement a custom CheckTxHandler, including:
- The parameters for
NewCustomCheckTxHandler - How to write your own handler function
- What considerations to keep in mind for deterministic validation
| func (oe *OptimisticExecution) WaitResult() (*abci.FinalizeBlockResponse, error) { | ||
| <-oe.stopCh | ||
| return oe.response, oe.err | ||
| } |
There was a problem hiding this comment.
WaitResult may dead-lock if OE never started.
<-oe.stopCh blocks forever when oe.stopCh is nil.
Return a meaningful error instead:
func (oe *OptimisticExecution) WaitResult() (*abci.FinalizeBlockResponse, error) {
- <-oe.stopCh
+ oe.mtx.Lock()
+ ch := oe.stopCh
+ oe.mtx.Unlock()
+
+ if ch == nil {
+ return nil, fmt.Errorf("optimistic execution not started")
+ }
+ <-ch
return oe.response, oe.err
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| func (oe *OptimisticExecution) WaitResult() (*abci.FinalizeBlockResponse, error) { | |
| <-oe.stopCh | |
| return oe.response, oe.err | |
| } | |
| func (oe *OptimisticExecution) WaitResult() (*abci.FinalizeBlockResponse, error) { | |
| oe.mtx.Lock() | |
| ch := oe.stopCh | |
| oe.mtx.Unlock() | |
| if ch == nil { | |
| return nil, fmt.Errorf("optimistic execution not started") | |
| } | |
| <-ch | |
| return oe.response, oe.err | |
| } |
| func (app *BaseApp) CheckTx(req *abci.CheckTxRequest) (*abci.CheckTxResponse, error) { | ||
| var mode execMode | ||
|
|
||
| switch { | ||
| case req.Type == abci.CheckTxType_New: | ||
| case req.Type == abci.CHECK_TX_TYPE_CHECK: | ||
| mode = execModeCheck | ||
|
|
||
| case req.Type == abci.CheckTxType_Recheck: | ||
| case req.Type == abci.CHECK_TX_TYPE_RECHECK: | ||
| mode = execModeReCheck | ||
|
|
||
| default: | ||
| return nil, fmt.Errorf("unknown RequestCheckTx type: %s", req.Type) | ||
| return nil, fmt.Errorf("unknown CheckTxRequest type: %s", req.Type) | ||
| } | ||
|
|
||
| gInfo, result, anteEvents, err := app.runTx(mode, req.Tx) | ||
| if err != nil { | ||
| return sdkerrors.ResponseCheckTxWithEvents(err, gInfo.GasWanted, gInfo.GasUsed, anteEvents, app.trace), nil | ||
| if app.checkTxHandler == nil { | ||
| gInfo, result, anteEvents, err := app.runTx(mode, req.Tx, nil) | ||
| if err != nil { | ||
| return sdkerrors.CheckTxResponseWithEvents(err, gInfo.GasWanted, gInfo.GasUsed, anteEvents, app.trace), nil | ||
| } | ||
|
|
||
| return &abci.CheckTxResponse{ | ||
| GasWanted: int64(gInfo.GasWanted), // TODO: Should type accept unsigned ints? | ||
| GasUsed: int64(gInfo.GasUsed), // TODO: Should type accept unsigned ints? | ||
| Log: result.Log, | ||
| Data: result.Data, | ||
| Events: sdk.MarkEventsToIndex(result.Events, app.indexEvents), | ||
| }, nil | ||
| } |
There was a problem hiding this comment.
CheckTx response omits Code / Codespace and may overflow gas conversion
-
The constructed
abci.CheckTxResponsedoes not propagateCodeandCodespacefromresult.
CometBFT relies onCode==0to decide whether the Tx should stay in the mempool.
Returning zero values unconditionally will let invalid Txs linger. -
GasWanted/GasUsedare down-cast fromuint64toint64. While unlikely, a
block-wide gas >math.MaxInt64would silently overflow and become negative.
@@ func (app *BaseApp) CheckTx(req *abci.CheckTxRequest) (*abci.CheckTxResponse, error) {
- return &abci.CheckTxResponse{
- GasWanted: int64(gInfo.GasWanted), // TODO: Should type accept unsigned ints?
- GasUsed: int64(gInfo.GasUsed), // TODO: Should type accept unsigned ints?
- Log: result.Log,
- Data: result.Data,
- Events: sdk.MarkEventsToIndex(result.Events, app.indexEvents),
- }, nil
+ return &abci.CheckTxResponse{
+ Code: result.Code,
+ Codespace: result.Codespace,
+ GasWanted: int64(gInfo.GasWanted), // consider keeping uint64 in a follow-up
+ GasUsed: int64(gInfo.GasUsed),
+ Log: result.Log,
+ Data: result.Data,
+ Events: sdk.MarkEventsToIndex(result.Events, app.indexEvents),
+ }, nil
}
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (1)
baseapp/abci_utils.go (1)
168-174: 🛠️ Refactor suggestionAvoid
int64 → intcast – possible overflow on 32-bit buildsThe custom comparator converts an
int64difference toint:return -int(vote1.Validator.Power - vote2.Validator.Power)On 32-bit platforms (or if
gois compiled with a 32-bitint), large voting–power values can overflow this cast and break the ordering predicate, causingslices.IsSortedFuncto return incorrect results.- return -int(vote1.Validator.Power - vote2.Validator.Power) // vp sorted in descending order + diff := vote1.Validator.Power - vote2.Validator.Power + switch { + case diff > 0: + return -1 // vote1 should come before vote2 + case diff < 0: + return 1 // vote1 should come after vote2 + default: + return 0 + }This avoids any narrowing conversion while keeping the descending order semantics intact.
🧹 Nitpick comments (12)
docs/docs/learn/advanced/00-baseapp.md (1)
435-435: Documentation updated to reflect new CometBFT v1 parameter typeThe ABCI request parameter type has been correctly updated to use the new
InitChainRequesttype from CometBFT v1.Consider rephrasing "in order to initialize" to "to initialize" for conciseness.
-The `InitChain(req abci.InitChainRequest)` method of `BaseApp` calls the [`initChainer()`](../beginner/00-app-anatomy.md#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](../../build/building-modules/08-genesis.md#initgenesis) function of each of the application's modules. +The `InitChain(req abci.InitChainRequest)` method of `BaseApp` calls the [`initChainer()`](../beginner/00-app-anatomy.md#initchainer) of the application to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](../../build/building-modules/08-genesis.md#initgenesis) function of each of the application's modules.🧰 Tools
🪛 LanguageTool
[style] ~435-~435: Consider a shorter alternative to avoid wordiness.
Context: ...tomy.md#initchainer) of the application in order to initialize the main state of the applic...(IN_ORDER_TO_PREMIUM)
docs/docs/building-modules/10-autocli.md (3)
20-20: Minor redundancy in phrasing.The phrase "CLI interface" is redundant since "I" in CLI already stands for "Interface".
-The `autocli` package is a [Go library](https://pkg.go.dev/cosmossdk.io/client/v2/autocli) for generating CLI (command line interface) interfaces for Cosmos SDK-based applications. It provides a simple way to add CLI commands to your application by generating them automatically based on your gRPC service definitions. Autocli generates CLI commands and flags directly from your protobuf messages, including options, input parameters, and output parameters. This means that you can easily add a CLI interface to your application without having to manually create and manage commands. +The `autocli` package is a [Go library](https://pkg.go.dev/cosmossdk.io/client/v2/autocli) for generating CLI (command line interface) for Cosmos SDK-based applications. It provides a simple way to add CLI commands to your application by generating them automatically based on your gRPC service definitions. Autocli generates CLI commands and flags directly from your protobuf messages, including options, input parameters, and output parameters. This means that you can easily add a CLI to your application without having to manually create and manage commands.🧰 Tools
🪛 LanguageTool
[style] ~20-~20: This phrase is redundant (‘I’ stands for ‘interface’). Use simply “CLI”.
Context: ...s. This means that you can easily add a CLI interface to your application without having to m...(ACRONYM_TAUTOLOGY)
24-30: Grammar issues in the Getting Started section.There are a few grammatical errors in this section.
-2. Configure how behave `autocli` command generation, by implementing the `func (am AppModule) AutoCLIOptions() *autocliv1.ModuleOptions` method on the module. Learn more [here](#advanced-usage). -3. Use the `autocli.AppOptions` struct to specifies the modules you defined. If you are using the `depinject` package to manage your app's dependencies, it can automatically create an instance of `autocli.AppOptions` based on your app's configuration. -4. Use the `EnhanceRootCommand()` method provided by `autocli` to add the CLI commands for the specified modules to your root command and can also be found in the `client/v2/autocli/app.go` file. Additionally, this method adds the `autocli` functionality to your app's root command. This method is additive only, meaning that it does not create commands if they are already registered for a module. Instead, it adds any missing commands to the root command. +2. Configure how to behave `autocli` command generation, by implementing the `func (am AppModule) AutoCLIOptions() *autocliv1.ModuleOptions` method on the module. Learn more [here](#advanced-usage). +3. Use the `autocli.AppOptions` struct to specify the modules you defined. If you are using the `depinject` package to manage your app's dependencies, it can automatically create an instance of `autocli.AppOptions` based on your app's configuration. +4. Use the `EnhanceRootCommand()` method provided by `autocli` to add the CLI commands for the specified modules to your root command, which can also be found in the `client/v2/autocli/app.go` file. Additionally, this method adds the `autocli` functionality to your app's root command. This method is additive only, meaning that it does not create commands if they are already registered for a module. Instead, it adds any missing commands to the root command.🧰 Tools
🪛 LanguageTool
[uncategorized] ~27-~27: Possible missing preposition found.
Context: ....AppModuleinterface. 2. Configure how behaveautocli` command generation, by implem...(AI_HYDRA_LEO_MISSING_TO)
[uncategorized] ~28-~28: This verb does not appear to agree with the subject. Consider using a different form.
Context: ... Use theautocli.AppOptionsstruct to specifies the modules you defined. If you are usi...(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
[uncategorized] ~29-~29: Possible missing comma found.
Context: ... for the specified modules to your root command and can also be found in the `client/v2...(AI_HYDRA_LEO_MISSING_COMMA)
153-153: Another redundancy in Conclusion section."CLI interfaces" is redundant.
-`autocli` is a powerful tool for adding CLI interfaces to your Cosmos SDK-based applications. It allows you to easily generate CLI commands and flags from your protobuf messages, and provides many options for customising the behavior of your CLI application. +`autocli` is a powerful tool for adding CLI to your Cosmos SDK-based applications. It allows you to easily generate CLI commands and flags from your protobuf messages, and provides many options for customising the behavior of your CLI application.🧰 Tools
🪛 LanguageTool
[style] ~153-~153: This phrase is redundant (‘I’ stands for ‘interfaces’). Use simply “CLIs”.
Context: ...autocliis a powerful tool for adding CLI interfaces to your Cosmos SDK-based applications. ...(ACRONYM_TAUTOLOGY)
docs/docs/build/abci/04-checktx.md (1)
21-27: Typo in CheckTxHandler description.There's a minor typo in the explanation.
-`CheckTxHandler` allows users to extend the logic of `CheckTx`. `CheckTxHandler` is called by pasding context and the transaction bytes received through ABCI. It is required that the handler returns deterministic results given the same transaction bytes. +`CheckTxHandler` allows users to extend the logic of `CheckTx`. `CheckTxHandler` is called by passing context and the transaction bytes received through ABCI. It is required that the handler returns deterministic results given the same transaction bytes.api/cosmos/autocli/v1/options.pulsar.go (1)
1-2: *Consider excluding generated .pulsar.go files from VCSThis file is 5 KLOC of fully-generated protobuf reflection code. Keeping generated artifacts under git often:
• Inflates diffs & merge conflicts
• Slows reviews (as seen here)
• Risks accidental manual editsUnless there is a build-time or tooling constraint, you can commit only the
*.protofiles and generate Go code in CI (e.g. viago generateormake proto). Doing so will keep the repository leaner and code reviews focused on hand-written logic.go.mod (1)
200-201: Local replace directive requires reproducibility plan
replace cosmossdk.io/api => ./apipoints at a local folder. Builds outside this repository (e.g. downstream SDK users or reproducible CI pipelines) will fail unless the folder layout is preserved.Consider publishing
cosmossdk.io/apias a tagged module or documenting the requiredgo.workworkspace file so consumers can build the SDK without manual path rewrites.api/cosmos/staking/v1beta1/genesis.pulsar.go (1)
891-899: Large-string length cast can overflow on > 2 GiB payloads (low risk)The generated unmarshal code casts
stringLen(uint64) toint.
If a malicious genesis file encodes a single string longer thanmath.MaxInt, the cast overflows silently before the earlier bounds checks run.This is standard
protoc-gen-gooutput and usually accepted, but if you ever validate untrusted genesis files you might wish to introduce an upper-bound check (e.g.if stringLen > 16<<20 { ... }).Also applies to: 1301-1352
api/cosmos/base/tendermint/v1beta1/query.pulsar.go (1)
4-9: Aliasv11is functional but hurts readabilityThe alias
v11does work, however future maintainers are unlikely to guess thatv11represents the p2p package.
If this file ever needs to be inspected or hand-patched, a more descriptive alias such asp2pv1would be easier on the eyes and avoid magic numbers.-import ( - v11 "buf.build/gen/go/cometbft/cometbft/protocolbuffers/go/cometbft/p2p/v1" +import ( + p2pv1 "buf.build/gen/go/cometbft/cometbft/protocolbuffers/go/cometbft/p2p/v1"Not a blocking issue (generated code rarely gets read), but worth considering if the generator can be tweaked.
baseapp/baseapp.go (1)
865-870: RunTx overload is sensible, but guard against inconsistent inputAccepting both
txBytesand (optionally) a decodedsdk.Txavoids double-decoding—nice!
Two small suggestions:
- Add an early sanity check to ensure that when both parameters are supplied they match (same hash), preventing subtle bugs:
if tx != nil { if bz, err := app.txEncoder(tx); err == nil && !bytes.Equal(bz, txBytes) { return gInfo, nil, nil, fmt.Errorf("runTx: provided tx and txBytes mismatch") } }
- Document clearly in the comment that
txmay benil, buttxBytesmust never benil/empty, otherwise the later hash computation panics.api/cosmos/store/v1beta1/listening.pulsar.go (1)
807-871: Type switch-over looks correct, but mind on-disk bloatThe switch from Tendermint v0 to CometBFT v1 ABCI types (
CommitResponse,FinalizeBlockRequest/Response) is implemented consistently across:
Set,Mutable,NewField- descriptor indexes & raw proto spec
Functionally 👍.
A minor operational note: both
FinalizeBlockRequestandFinalizeBlockResponseembed the full list of tx results, events, etc. Persisting them verbatim inBlockMetadatacan grow the streaming files considerably (especially after the proto-v1 refactor where more fields are populated).If file size is a concern, think about persisting only the hash or a trimmed struct instead of the full request/response.
baseapp/abci.go (1)
1071-1096: Unsafe struct-to-struct cast between different packagesThe response from
store.Queryableis cast with:abciResp := abci.QueryResponse(*resp)
storetypes.ResponseQueryandabci.QueryResponseare no longer guaranteed to be identical after the CometBFT v1 migration. A blind cast risks latent memory/layout errors if the structs diverge.Prefer explicit construction:
resp.Height = req.Height -abciResp := abci.QueryResponse(*resp) +abciResp := abci.QueryResponse{ + Code: resp.Code, + Codespace: resp.Codespace, + Log: resp.Log, + Info: resp.Info, + Index: resp.Index, + Key: resp.Key, + Value: resp.Value, + ProofOps: resp.ProofOps, + Height: resp.Height, + // add new fields here as CometBFT evolves +}This is more verbose but future-proof and safer.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (30)
api/cosmos/staking/v1beta1/query_grpc.pb.gois excluded by!**/*.pb.goapi/cosmos/staking/v1beta1/tx_grpc.pb.gois excluded by!**/*.pb.goapi/go.sumis excluded by!**/*.sumapi/tendermint/abci/types_grpc.pb.gois excluded by!**/*.pb.goclient/grpc/cmtservice/query.pb.gois excluded by!**/*.pb.goclient/grpc/cmtservice/types.pb.gois excluded by!**/*.pb.gogo.sumis excluded by!**/*.sumorm/go.sumis excluded by!**/*.sumorm/internal/testpb/bank.pb.gois excluded by!**/*.pb.goorm/internal/testpb/bank_query.pb.gois excluded by!**/*.pb.goorm/internal/testpb/bank_query_grpc.pb.gois excluded by!**/*.pb.goorm/internal/testpb/test_schema.pb.gois excluded by!**/*.pb.goorm/internal/testpb/test_schema_query.pb.gois excluded by!**/*.pb.goorm/internal/testpb/test_schema_query_grpc.pb.gois excluded by!**/*.pb.goproto/buf.lockis excluded by!**/*.locksimapp/go.sumis excluded by!**/*.sumstore/go.sumis excluded by!**/*.sumstore/streaming/abci/grpc.pb.gois excluded by!**/*.pb.gostore/types/listening.pb.gois excluded by!**/*.pb.gotests/go.sumis excluded by!**/*.sumtypes/abci.pb.gois excluded by!**/*.pb.gotypes/tx/service.pb.gois excluded by!**/*.pb.gox/circuit/go.sumis excluded by!**/*.sumx/consensus/types/query.pb.gois excluded by!**/*.pb.gox/consensus/types/tx.pb.gois excluded by!**/*.pb.gox/evidence/go.sumis excluded by!**/*.sumx/feegrant/go.sumis excluded by!**/*.sumx/nft/go.sumis excluded by!**/*.sumx/staking/types/staking.pb.gois excluded by!**/*.pb.gox/upgrade/go.sumis excluded by!**/*.sum
📒 Files selected for processing (61)
CHANGELOG.md(1 hunks)api/cosmos/app/runtime/v1alpha1/module.pulsar.go(17 hunks)api/cosmos/autocli/v1/options.pulsar.go(29 hunks)api/cosmos/base/abci/v1beta1/abci.pulsar.go(27 hunks)api/cosmos/base/tendermint/v1beta1/query.pulsar.go(24 hunks)api/cosmos/base/tendermint/v1beta1/types.pulsar.go(21 hunks)api/cosmos/consensus/v1/query.pulsar.go(9 hunks)api/cosmos/consensus/v1/tx.pulsar.go(20 hunks)api/cosmos/staking/v1beta1/genesis.pulsar.go(16 hunks)api/cosmos/staking/v1beta1/staking.pulsar.go(18 hunks)api/cosmos/store/streaming/abci/grpc.pulsar.go(16 hunks)api/cosmos/store/v1beta1/listening.pulsar.go(11 hunks)api/cosmos/tx/v1beta1/service.pulsar.go(11 hunks)api/go.mod(1 hunks)api/tendermint/crypto/keys.pulsar.go(0 hunks)api/tendermint/libs/bits/types.pulsar.go(0 hunks)api/tendermint/types/block.pulsar.go(0 hunks)api/tendermint/types/validator.pulsar.go(0 hunks)api/tendermint/version/types.pulsar.go(0 hunks)baseapp/abci.go(31 hunks)baseapp/abci_test.go(91 hunks)baseapp/abci_utils.go(8 hunks)baseapp/abci_utils_test.go(7 hunks)baseapp/baseapp.go(10 hunks)baseapp/baseapp_test.go(27 hunks)baseapp/block_gas_test.go(2 hunks)baseapp/grpcrouter.go(3 hunks)baseapp/grpcrouter_helpers.go(1 hunks)baseapp/info.go(2 hunks)baseapp/msg_service_router_test.go(2 hunks)baseapp/oe/optimistic_execution.go(4 hunks)baseapp/oe/optimistic_execution_test.go(1 hunks)baseapp/options.go(1 hunks)baseapp/params.go(1 hunks)baseapp/params_legacy.go(1 hunks)baseapp/snapshot_test.go(9 hunks)baseapp/streaming_test.go(7 hunks)baseapp/test_helpers.go(4 hunks)baseapp/testutil/mock/mocks.go(1 hunks)baseapp/utils_test.go(1 hunks)client/grpc/cmtservice/block.go(1 hunks)client/grpc/cmtservice/service.go(2 hunks)client/grpc/cmtservice/types.go(1 hunks)client/grpc/cmtservice/util.go(1 hunks)client/grpc_query.go(1 hunks)client/grpc_query_test.go(1 hunks)client/query.go(5 hunks)client/rpc/block.go(1 hunks)client/rpc/rpc_test.go(1 hunks)client/rpc/tx.go(3 hunks)client/utils.go(1 hunks)client/v2/CHANGELOG.md(1 hunks)crypto/codec/amino.go(0 hunks)crypto/codec/cmt.go(1 hunks)crypto/keys/multisig/codec.go(0 hunks)docs/docs/build/abci/04-checktx.md(1 hunks)docs/docs/building-modules/10-autocli.md(1 hunks)docs/docs/learn/advanced/00-baseapp.md(2 hunks)docs/docs/learn/advanced/15-upgrade.md(1 hunks)go.mod(9 hunks)orm/go.mod(1 hunks)
💤 Files with no reviewable changes (7)
- crypto/keys/multisig/codec.go
- crypto/codec/amino.go
- api/tendermint/version/types.pulsar.go
- api/tendermint/crypto/keys.pulsar.go
- api/tendermint/libs/bits/types.pulsar.go
- api/tendermint/types/validator.pulsar.go
- api/tendermint/types/block.pulsar.go
👮 Files not reviewed due to content moderation or server errors (1)
- api/cosmos/tx/v1beta1/service.pulsar.go
🧰 Additional context used
🧬 Code Graph Analysis (6)
baseapp/options.go (2)
baseapp/baseapp.go (1)
BaseApp(67-209)types/abci.go (1)
CheckTxHandler(29-29)
client/grpc_query_test.go (1)
testutil/sims/app_helpers.go (1)
DefaultConsensusParams(36-51)
baseapp/abci_utils_test.go (1)
types/abci.go (1)
PrepareProposalHandler(24-24)
baseapp/test_helpers.go (1)
baseapp/baseapp.go (1)
BaseApp(67-209)
baseapp/abci_utils.go (2)
types/context.go (1)
Context(41-73)types/abci.go (4)
PrepareProposalHandler(24-24)ProcessProposalHandler(21-21)ExtendVoteHandler(32-32)VerifyVoteExtensionHandler(36-36)
api/cosmos/consensus/v1/tx.pulsar.go (2)
core/comet/service.go (1)
Evidence(44-50)x/consensus/types/tx.pb.go (3)
MsgUpdateParams(35-50)MsgUpdateParams(54-54)MsgUpdateParams(55-57)
🪛 LanguageTool
docs/docs/learn/advanced/00-baseapp.md
[style] ~435-~435: Consider a shorter alternative to avoid wordiness.
Context: ...tomy.md#initchainer) of the application in order to initialize the main state of the applic...
(IN_ORDER_TO_PREMIUM)
docs/docs/building-modules/10-autocli.md
[style] ~20-~20: This phrase is redundant (‘I’ stands for ‘interface’). Use simply “CLI”.
Context: ...s. This means that you can easily add a CLI interface to your application without having to m...
(ACRONYM_TAUTOLOGY)
[uncategorized] ~27-~27: Possible missing preposition found.
Context: ....AppModuleinterface. 2. Configure how behaveautocli` command generation, by implem...
(AI_HYDRA_LEO_MISSING_TO)
[uncategorized] ~28-~28: This verb does not appear to agree with the subject. Consider using a different form.
Context: ... Use the autocli.AppOptions struct to specifies the modules you defined. If you are usi...
(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
[uncategorized] ~29-~29: Possible missing comma found.
Context: ... for the specified modules to your root command and can also be found in the `client/v2...
(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~104-~104: Possible missing comma found.
Context: ...is defined in the appmodule.AppModule implementation located in the x/gov/autocli.go file....
(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~153-~153: This phrase is redundant (‘I’ stands for ‘interfaces’). Use simply “CLIs”.
Context: ...autocli is a powerful tool for adding CLI interfaces to your Cosmos SDK-based applications. ...
(ACRONYM_TAUTOLOGY)
🪛 GitHub Check: gosec
api/cosmos/autocli/v1/options.pulsar.go
[failure] 1484-1484: integer overflow conversion uint64 -> uint8
integer overflow conversion uint64 -> int
api/cosmos/staking/v1beta1/genesis.pulsar.go
[failure] 1339-1339: integer overflow conversion uint64 -> uint8
integer overflow conversion uint64 -> int
api/cosmos/app/runtime/v1alpha1/module.pulsar.go
[failure] 1518-1518: integer overflow conversion uint64 -> uint8
integer overflow conversion uint64 -> int
🔇 Additional comments (165)
api/cosmos/app/runtime/v1alpha1/module.pulsar.go (1)
389-434:PreBlockerslist integration looks soundThe new
_Module_10_listwrapper and the accompanying fast-reflection plumbing (fields, marshal/unmarshal paths, size accounting, etc.) are consistent with the patterns used for the prior repeated-string fields. Tag10is unique, and the panic message inAppendMutablecorrectly references thePreBlockersfield.
Nothing else to flag here. 👍client/grpc/cmtservice/util.go (1)
4-7: Double-check the CometBFT v1 import path is present in go.modThe import move to
github.com/cometbft/cometbft/api/cometbft/types/v1is correct for the v1 protobufs.
Please confirm:
go.mod/go.sumcontain this new module path (it’s easy to miss during large renames).- All previous
"github.com/cometbft/cometbft/proto/tendermint/types"references were updated, otherwise there will be duplicate proto definitions in the build.If you’d like, I can supply a quick shell scan to verify there are no lingering old-path imports.
client/v2/CHANGELOG.md (1)
83-85: Changelog entry LGTMThe new bullet for PR cosmos#20266 correctly lands in the “Features” section for beta 2. No further action required.
CHANGELOG.md (1)
41-41: LGTM: Well-formatted changelog entry for the new CheckTxHandlerThe addition properly documents the creation of a new
CheckTxHandlerfeature that allows extending theCheckTxlogic, following the project's changelog conventions with component name, PR reference, and clear description.client/grpc/cmtservice/block.go (1)
6-6: LGTM: Appropriate import path migration to CometBFT v1This change correctly updates the import path from Tendermint protobuf to the new CometBFT v1 API, which is consistent with the overall migration to CometBFT v1 mentioned in the PR objectives.
client/rpc/block.go (1)
9-9: LGTM: Consistent update to CometBFT v1 import pathThis change properly updates the import path while maintaining the same alias (
cmt), ensuring compatibility with the rest of the file while migrating to CometBFT v1 types.baseapp/grpcrouter_helpers.go (1)
48-48: LGTM: Updated to use new ABCI query request typeThe code correctly uses the new
abci.QueryRequesttype instead of the deprecatedabci.RequestQuery, which is consistent with the CometBFT v1 integration objective of this PR.baseapp/testutil/mock/mocks.go (1)
11-11: Import path updated to CometBFT v1 APIThe import path for the
cryptopackage has been updated to use CometBFT v1's new API structure. This aligns with the broader migration from Tendermint to CometBFT v1 protobuf types.baseapp/params_legacy.go (1)
41-41: Import path updated to CometBFT v1 APIThe import path for
cmtprotohas been updated to use the new CometBFT v1 API structure. This ensures that consensus parameters (BlockParams, EvidenceParams, ValidatorParams) are sourced from the updated protobuf definitions.baseapp/utils_test.go (1)
16-16: Import path updated to CometBFT v1 APIThe import path for
cmtprotohas been updated to use the new CometBFT v1 API structure, ensuring that test utilities for consensus parameters use the latest protobuf definitions.client/rpc/rpc_test.go (1)
97-102: Updated to use new CometBFT v1 ABCI typeThe code has been updated to use
abci.QueryRequestinstead of the deprecatedabci.RequestQuery, aligning with CometBFT v1's ABCI interface changes. The fields and functionality remain the same, ensuring backward compatibility while modernizing the API usage.baseapp/params.go (1)
6-6: Import path correctly updated for CometBFT v1The import path for the
cmtprotopackage has been updated to use the new CometBFT v1 API path, which is consistent with the objective of migrating to CometBFT v1.docs/docs/learn/advanced/00-baseapp.md (1)
207-207: Documentation updated to reflect new CometBFT v1 type namesThe type name has been correctly updated from
RequestInitChaintoInitChainRequestto match the CometBFT v1 API naming convention.client/grpc_query.go (1)
86-90: ABCI query request type correctly updated for CometBFT v1The ABCI query request type has been updated from
RequestQuerytoQueryRequestto align with the CometBFT v1 naming convention, while maintaining the same field structure and functionality.baseapp/msg_service_router_test.go (2)
153-154: Test code updated to use new CometBFT v1 type nameThe ABCI request type has been correctly updated to use
FinalizeBlockRequestinstead of the previousRequestFinalizeBlockto match the CometBFT v1 API naming convention.
199-201: Test code updated to use new CometBFT v1 type nameThe ABCI request type has been correctly updated to use
FinalizeBlockRequestfor consistency with the CometBFT v1 API naming convention. The test functionality remains unchanged.baseapp/options.go (1)
353-360: Implementation ofSetCheckTxHandlerlooks goodThis new method allows customization of transaction validation logic by setting a custom
checkTxHandlerfield in theBaseApp. The implementation follows the same pattern as other setter methods in this file, including checking whether theBaseAppis sealed before making changes.api/go.mod (1)
6-6: Dependency updates align with CometBFT v1 integrationThe addition of
buf.build/gen/go/cometbft/cometbft/protocolbuffers/godependency and updates to protobuf versions properly support the migration from Tendermint to CometBFT v1 protobuf types.Also applies to: 11-11, 15-15
baseapp/block_gas_test.go (1)
118-118: ABCI request types correctly updatedThe code properly updates from deprecated Tendermint ABCI types to new CometBFT v1 types:
abci.RequestInitChain→abci.InitChainRequestabci.RequestFinalizeBlock→abci.FinalizeBlockRequestThis is consistent with the CometBFT v1 integration objective.
Also applies to: 158-158
client/grpc_query_test.go (1)
86-86: ABCI request types correctly updatedThe code properly updates from deprecated Tendermint ABCI types to new CometBFT v1 types:
abci.RequestInitChain→abci.InitChainRequestabci.RequestFinalizeBlock→abci.FinalizeBlockRequestThis is consistent with the CometBFT v1 integration objective.
Also applies to: 93-93
crypto/codec/cmt.go (1)
4-4: Import path updated to use CometBFT v1 APIThe import path has been updated from the legacy Tendermint protobuf package to the new CometBFT v1 API path. This is consistent with the PR objective of migrating to CometBFT v1.
client/utils.go (1)
81-81:Details
❓ Verification inconclusive
WebSocket path removed from RPC client initialization
The explicit
/websocketpath has been removed from therpchttp.New()call. This change aligns with CometBFT's conventions for client connections.
🏁 Script executed:
#!/bin/bash # Check how rpchttp.New is implemented in CometBFT to confirm this change is appropriate rg -A 5 "func New\(" --glob "rpchttp/*.go"Length of output: 193
Unable to verify
rpchttp.Newimplementation locallyI couldn’t find a local
rpchttppackage to confirm whetherrpchttp.New(nodeURI)now applies the/websocketpath by default. Please manually verify that this change aligns with CometBFT’s conventions:
- Location:
client/utils.go:81- Action: Inspect the external CometBFT
rpchttp.Newimplementation to ensure the WebSocket endpoint is applied implicitly.baseapp/info.go (2)
148-148: Updated to use PrepareProposalRequest from CometBFT v1Changed the embedded type from
*abci.RequestPrepareProposalto*abci.PrepareProposalRequestto align with CometBFT v1's naming conventions.
162-162: Field access updated for new PrepareProposalRequest typeUpdated references to access fields through the new
PrepareProposalRequesttype instead of the previousRequestPrepareProposaltype, maintaining consistent access patterns.Also applies to: 166-166
docs/docs/learn/advanced/15-upgrade.md (1)
106-108: Documentation updated for CometBFT v1 compatibilityThe
InitChainerfunction signature in the documentation has been updated to useabci.InitChainRequestinstead ofabci.RequestInitChain, and a required line for saving module consensus versions has been added to the example.client/rpc/tx.go (3)
26-51: Function renamed to match conventionThe function
newTxResponseCheckTxhas been appropriately renamed tonewTxCheckTxResponseto follow consistent naming patterns where the action ("CheckTx") comes before the type ("Response").
85-87: Updated function call to match new nameUpdated call to the renamed function, maintaining consistent behavior.
122-123:Details
✅ Verification successful
Simplified RPC client initialization
Removed the explicit "/websocket" path argument, now relying on CometBFT's default path resolution. This change aligns with CometBFT v1's updated client initialization pattern.
🏁 Script executed:
#!/bin/bash # Verify how the client is initialized in other places in the codebase rg "rpchttp.New" --type go -A 1 -B 1Length of output: 506
Confirmed: Consistent RPC Client Initialization
The removal of the explicit “/websocket” suffix is in line with all other
rpchttp.Newcalls in the codebase:
- server/start.go:
rpcclient, err := rpchttp.New(svrCtx.Config.RPC.ListenAddress)- client/utils.go:
func NewClientFromNode(nodeURI string) (*rpchttp.HTTP, error) { return rpchttp.New(nodeURI) }- client/rpc/tx.go (this PR):
c, err := rpchttp.New(clientCtx.NodeURI)No further changes are needed.
client/query.go (5)
51-57: Updated ABCI query types in function signature and commentsThe function signature and documentation have been updated to use the new CometBFT v1 protobuf types (
QueryRequestinstead ofRequestQuery), maintaining API compatibility while transitioning to the new type system.
79-101: Updated internal query method signature and error returnsThe implementation of
queryABCIhas been updated to use the new CometBFT v1 types (QueryRequest/QueryResponse) while preserving the same functionality.
104-105: Updated error handling to use new response typeError handling has been updated to work with the new
QueryResponsetype.
115-126: Updated error conversion function signatureThe
sdkErrorToGRPCErrorfunction now accepts the newQueryResponsetype while maintaining the same error mapping logic.
132-136: Updated query constructor to use new ABCI request typeThe query method now constructs a
QueryRequestinstead of aRequestQuerywhile preserving the same field values.baseapp/test_helpers.go (5)
4-5: Updated import path for CometBFT protobuf typesImport path has been updated from the deprecated Tendermint proto path to the new CometBFT API v1 path.
22-23: Added decoded transaction to runTx callThe
runTxmethod call now includes thetxparameter to avoid redundant decoding inside the method, improving performance.
28-29: Added nil as decoded transaction parameterAdded
nilas the third parameter since no decoded transaction is available in theSimulatemethod, conforming to the updatedrunTxsignature.
39-40: Added decoded transaction to SimDeliver runTx callThe
runTxmethod call inSimDelivernow includes the already decodedtxparameter to avoid redundant decoding.
50-51: Added decoded transaction to SimTxFinalizeBlock runTx callThe
runTxmethod call inSimTxFinalizeBlocknow includes the already decodedtxparameter to avoid redundant decoding.baseapp/abci_utils_test.go (4)
9-11: Updated import paths for CometBFT v1 protobuf packagesImport paths have been updated from the deprecated Tendermint proto paths to the new CometBFT API v1 paths (
cmtprotocryptoandcmtproto).
498-499: Updated ABCI request type in test casesThe test case struct now uses the new CometBFT v1
PrepareProposalRequesttype instead of the deprecatedRequestPrepareProposaltype.Also applies to: 503-504
515-516: Updated proposal request instantiationUpdated the test cases to instantiate the new
PrepareProposalRequesttype while maintaining the same test data.Also applies to: 523-524, 535-536
618-619: Updated ABCI request type in priority mempool testsThe test cases for priority nonce mempool transaction selection now use the new CometBFT v1
PrepareProposalRequesttype, maintaining test coverage while adapting to the new API.Also applies to: 625-626, 633-634, 642-643, 652-653
baseapp/oe/optimistic_execution_test.go (2)
14-14: Clean migration to CometBFT v1 typesThe function signature has been correctly updated to use the new CometBFT v1
FinalizeBlockRequestandFinalizeBlockResponsetypes instead of the previous Tendermint types.
21-21: Properly updated to new CometBFT v1 typeThe optimistic execution test now correctly uses the new
ProcessProposalRequesttype from CometBFT v1, which is consistent with the PR's objective of integrating CometBFT v1.baseapp/baseapp_test.go (2)
13-13: Correct import path for CometBFT v1 typesThe import has been properly updated from Tendermint proto types to CometBFT proto types with the correct package path.
101-102: Comprehensive migration to CometBFT v1 ABCI typesAll ABCI request and response types have been consistently updated throughout the test file:
RequestFinalizeBlock→FinalizeBlockRequestRequestInitChain→InitChainRequestRequestQuery→QueryRequestThe test logic remains unchanged, ensuring compatibility with the new CometBFT v1 API.
Also applies to: 106-107, 130-133, 165-169, 216-219, 227-228, 253-254, 260-261, 283-286, 389-392, 398-401, 418-422, 527-530, 552-553, 567-570, 667-670, 678-680, 694-697, 699-702, 721-724, 801-802, 821-822, 861-866
client/grpc/cmtservice/service.go (2)
28-28: Type alias correctly updated to CometBFT v1 ABCI typesThe
abciQueryFntype alias has been properly updated to use the new CometBFT v1QueryRequestandQueryResponsetypes instead of the previous Tendermint types.
249-249: Function calls correctly updated for CometBFT v1 compatibilityThe query execution and response conversion calls have been properly updated to work with the new CometBFT v1 ABCI types:
req.ToABCIQueryRequest()now returns a*abci.QueryRequestFromABCIQueryResponse(res)now accepts a*abci.QueryResponseThis maintains functional compatibility while using the new type system.
Also applies to: 253-253
client/grpc/cmtservice/types.go (2)
7-9: Function comments and signature correctly updated for CometBFT v1The
ToABCIQueryRequestfunction comments and signature have been properly updated to work with the new CometBFT v1 ABCI types. The function now returns a*abci.QueryRequestinstead of the previous Tendermint type.
18-20: Response conversion function updated for CometBFT v1 compatibilityThe
FromABCIQueryResponsefunction signature and comments have been correctly updated to accept a*abci.QueryResponsefrom the new CometBFT v1 type system while maintaining the same conversion logic.baseapp/grpcrouter.go (2)
53-53: Type signature updated for CometBFT v1 compatibilityThe
GRPCQueryHandlertype has been correctly updated to use the new CometBFT ABCI types, changing from*abci.RequestQueryto*abci.QueryRequestas input and*abci.ResponseQueryto*abci.QueryResponseas output.
106-128: Handler implementation updated to use new ABCI typesThe handler implementation has been properly updated to match the new ABCI type signature. The internal logic remains unchanged, preserving the existing behavior while adopting the new CometBFT types.
api/cosmos/consensus/v1/query.pulsar.go (5)
5-5: Import updated for CometBFT v1 compatibilityThe import has been correctly updated to use the CometBFT protobuf types from
buf.build/gen/go/cometbft/cometbft/protocolbuffers/go/cometbft/types/v1instead of the Tendermint types.
530-530: Updated ConsensusParams type referencesAll references to the ConsensusParams type have been properly updated to use the CometBFT v1 implementation instead of the Tendermint implementation.
Also applies to: 553-553, 570-570
859-859: ConsensusParams field type updatedThe
Paramsfield type in theQueryParamsResponsemessage has been correctly updated to use the CometBFT v1 ConsensusParams type.Also applies to: 882-882
897-927: Proto descriptor updated for CometBFTThe protobuf file descriptor raw data has been correctly updated to reference the CometBFT types instead of Tendermint types, ensuring proper serialization and deserialization.
944-950: Updated type references in Go type mappingsThe Go type mappings for the protobuf messages have been correctly updated to reference the CometBFT v1 ConsensusParams type.
orm/go.mod (5)
12-12: Dependency upgrade for cosmos-db looks good.The cosmos-db dependency was upgraded from v1.0.2 to v1.1.1, which aligns with the CometBFT v1 integration.
18-21: Core dependency version upgrades.The testify and protobuf libraries have been upgraded to newer versions, which is necessary for compatibility with CometBFT v1.
27-37: Indirect dependency updates.Multiple indirect dependencies have been updated, including DataDog/zstd, cockroachdb packages, and error handling libraries. These updates support the migration to CometBFT v1.
58-67: Monitoring and utility library updates.Prometheus client libraries and other utility dependencies have been updated to their latest versions, improving compatibility and potentially fixing security issues.
3-5:Details
✅ Verification successful
Go version and toolchain upgrade.
The Go version has been updated to 1.23.0 with toolchain specified as 1.23.5. These are very recent Go versions which may require developers to update their environments.
🌐 Web query:
What is the latest stable version of Go as of May 2025?💡 Result:
As of May 2025, the latest stable version of Go is 1.24.2, which was released on April 1, 2025[3]. This is part of the Go 1.24 major release line that was initially released on February 11, 2025[1].
Go 1.24 brought several changes and improvements to the language, including full support for generic type aliases and new features for WebAssembly, such as the
go:wasmexportcompiler directive for exporting functions to WebAssembly hosts[2].Following Go's versioning format of
go1.[major].[patch], where the second number is considered the major version number, Go 1.24.2 represents the second patch release in the 1.24 series[3]. This patch release included security fixes to thenet/httppackage and bug fixes to the compiler, runtime, and several other packages[1].Go follows a release policy where each major version is supported until there are two newer major releases[1]. The next major release, Go 1.25, is expected to be released in August 2025[9].
Citations:
- 1: https://go.dev/doc/devel/release
- 2: https://tip.golang.org/doc/go1.24
- 3: https://en.wikipedia.org/wiki/Go_(programming_language)
- 4: https://go.dev/dl/
- 5: https://blog.jetbrains.com/go/2025/01/16/the-goland-2025-1-early-access-program-has-started/
- 6: https://github.com/golang/tools/releases
- 7: https://blog.jetbrains.com/research/2025/04/is-golang-still-growing-go-language-popularity-trends-in-2024/
- 8: https://antonz.org/which-go/
- 9: https://tip.golang.org/doc/next
- 10: https://discussion.fedoraproject.org/t/fedora-doesnt-provide-latest-version-of-go/146930
Go version and toolchain update requires environment bump
The
orm/go.modnow specifies:go 1.23.0 toolchain go1.23.5As of May 2025, the latest stable Go release is 1.24.2 (April 1, 2025). Developers will need Go 1.23+ installed to build this module, and we recommend upgrading to Go 1.24.2 to benefit from the latest fixes and improvements.
- File: orm/go.mod (lines 3–5)
baseapp/streaming_test.go (5)
9-9: Updated import path for CometBFT v1 types.The import path has been updated from Tendermint protobuf types to the new CometBFT API v1 types, aligning with the PR objective.
32-32: Updated method signature for ListenFinalizeBlock.The ABCI message types have been updated to use the new CometBFT API naming conventions, which is consistent with the broader migration in the codebase.
36-36: Updated method signature for ListenCommit.The CommitResponse type is now used instead of the deprecated ResponseCommit type, maintaining consistency with the CometBFT v1 API changes.
54-57: Updated InitChain request type.InitChainRequest is now used with the correct import for ConsensusParams from the new CometBFT types package.
72-72: Updated FinalizeBlock method calls.All instances of FinalizeBlock method calls now use the new request type, ensuring compatibility with the CometBFT v1 API.
Also applies to: 97-97, 136-136
docs/docs/building-modules/10-autocli.md (2)
1-19: Documentation frontmatter and introduction setup.The new AutoCLI documentation has proper frontmatter with sidebar positioning and includes a helpful synopsis and pre-requisite readings section.
31-56: Well-structured documentation with clear examples.The documentation provides a comprehensive overview of AutoCLI with good code examples, clear sections on flags, commands, queries, and advanced usage patterns. The tutorial style with real Cosmos SDK module examples is very helpful.
Also applies to: 58-91, 92-152, 154-157
docs/docs/build/abci/04-checktx.md (3)
1-16: Clear explanation of CheckTx with Mermaid diagram.The documentation begins with a good overview of the CheckTx process and includes a helpful Mermaid diagram showing the interactions between components.
29-31: Clear type definition.The handler type definition is clear and concise.
33-50: Helpful implementation example.The example showing how to set a custom CheckTxHandler in an application's app.go file is valuable for developers implementing this feature.
baseapp/snapshot_test.go (5)
26-27: Updated ListSnapshots request and response types.The test has been updated to use the new CometBFT v1 API types for snapshot operations.
Also applies to: 36-39
125-126: Updated ListSnapshots and FinalizeBlock method calls.These method calls have been updated to use the new CometBFT v1 API types, maintaining consistent usage throughout the codebase.
Also applies to: 135-136
153-154: Updated Query method calls.The Query method calls now use the new request types, ensuring consistent usage of the CometBFT v1 API.
Also applies to: 159-160
198-202: Updated snapshot-related types and enum constants.All snapshot API types and enum constants have been updated to follow the CometBFT v1 naming conventions. The test logic remains unchanged, maintaining test coverage while adapting to the new API.
Also applies to: 204-205, 231-246
257-266: Updated remaining snapshot operation types.The remaining snapshot operations (OfferSnapshot, ApplySnapshotChunk, LoadSnapshotChunk) have been updated to use the CometBFT v1 types and constants, completing the migration of this test file.
Also applies to: 267-276, 307-310, 313-323, 327-343
baseapp/oe/optimistic_execution.go (5)
18-18: Type signature updated to use CometBFT types.The function signature has been properly migrated from Tendermint to the new CometBFT protobuf types.
28-29: Struct field types updated to use CometBFT types.Internal struct fields have been correctly updated to reference the new CometBFT protobuf types.
85-85: Method parameter updated to use CometBFT types.The
Executemethod parameter has been properly migrated from Tendermint to CometBFT protobuf types.
90-99: Request object construction updated to use CometBFT types.The request object construction has been correctly updated to use the new
FinalizeBlockRequesttype, with all fields properly mapped from the inputProcessProposalRequest.
157-157: Return type updated to use CometBFT types.The
WaitResultmethod return type has been properly migrated to use the new CometBFT protobuf type.baseapp/abci_test.go (15)
18-19: Updated imports to use CometBFT packages.The imports have been correctly updated to reference the new CometBFT API packages.
49-50: Request and response types updated to use CometBFT types.All ABCI request and response types have been properly migrated from Tendermint to CometBFT protobuf types, maintaining the same functionality.
Also applies to: 66-70, 91-94, 97-100, 103-108, 121-122, 140-144, 168-169, 207-211
290-303: Vote extension handlers updated to use CometBFT types.All vote extension related handlers and method calls have been properly migrated to use the new CometBFT types and constants.
Also applies to: 319-327, 340-363, 373-380, 397-420
433-435: ABCI handlers updated to use CometBFT types.All ABCI method handlers and calls have been properly updated to use the CometBFT protobuf types.
Also applies to: 442-445, 450-451, 455-458, 471-474, 478-481
514-517: Test method calls updated to use CometBFT types.All test method calls and assertions have been correctly updated to use the CometBFT protobuf types, maintaining test coverage and functionality.
Also applies to: 543-546, 570-573, 580-584, 615-618, 639-643, 665-668, 682-685, 714-718, 745-749, 762-794, 807-815, 819-829
1016-1020: Gas limit and block handling test functions updated to use CometBFT types.All gas limit and block handling related functions have been correctly migrated to use the new CometBFT types.
Also applies to: 1045-1052, 1054-1055, 1146-1152, 1165-1168, 1185-1189, 1193-1196, 1216-1219
1329-1336: Block retention test functions updated to use CometBFT types.All block retention related test functions have been properly migrated to use the CometBFT types.
Also applies to: 1360-1363, 1384-1387
1403-1406: Proposal handling functions updated to use CometBFT types.All proposal-related functions and status constants have been appropriately updated to the CometBFT API.
Also applies to: 1412-1415, 1427-1431, 1439-1446, 1449-1452
1465-1468: Proposal preparation and processing functions updated to use CometBFT types.All proposal preparation and processing functions have been correctly migrated to use the new CometBFT types and constants.
Also applies to: 1472-1477, 1482-1485, 1488-1492, 1497-1505, 1511-1513, 1517-1524, 1526-1530, 1535-1538, 1540-1544, 1548-1555, 1558-1562
1580-1583: MaxGas and handling test functions updated to use CometBFT types.All maximum gas limit and related test functions have been properly migrated to use the CometBFT types.
Also applies to: 1591-1595, 1610-1613, 1619-1623, 1634-1639, 1675-1679, 1698-1703, 1716-1719, 1725-1729, 1740-1744
1757-1760: Vote extension test functions updated to use CometBFT types.All vote extension related test functions have been properly migrated to use the new CometBFT types and constants.
Also applies to: 1762-1765, 1809-1818, 1826-1830, 1835-1841, 1872-1875, 1878-1895, 1902-1907, 1909-1919
1929-1934: State reset test functions updated to use CometBFT types.All state reset related test functions have been properly updated to use the CometBFT types.
Also applies to: 1937-1943, 1953-1954, 1967-1970, 1976-1977
2002-2011: PreBlocker and block height test functions updated to use CometBFT types.All block related functions and handlers have been correctly migrated to use the CometBFT types.
Also applies to: 2028-2031, 2032-2039, 2043-2044, 2058-2059
2088-2094: Vote extension integration with proposal handling updated to use CometBFT types.All vote extension integration with proposal handling logic has been properly migrated to use the CometBFT types.
Also applies to: 2096-2105, 2107-2126, 2128-2141, 2143-2166, 2170-2177, 2182-2184, 2199-2209, 2226-2231, 2299-2302, 2303-2304
2322-2328: Remaining test functions updated to use CometBFT types.All remaining test functions and assertions have been properly migrated to use the new CometBFT types and constants.
Also applies to: 2332-2343, 2359-2364, 2371-2374, 2378-2386, 2420-2423, 2429-2432, 2447-2451, 2456-2459, 2477-2484, 2487-2491
api/cosmos/staking/v1beta1/staking.pulsar.go (5)
5-6: Imports updated to use CometBFT protobuf packagesThe import statements have been correctly updated to use the new CometBFT protobuf packages instead of the legacy Tendermint packages. This is consistent with the overall migration to CometBFT v1.
250-250: Type references updated to use CometBFT Header typeAll references to the Tendermint
Headertype have been properly updated to use the CometBFT equivalentv1.Header. This change is consistent across all usage locations including method parameters, struct fields, and object initializations.Also applies to: 277-277, 300-300, 522-522, 14467-14467
12191-12191: ValidatorUpdate references migrated to CometBFT implementationAll references to the Tendermint
ValidatorUpdatetype have been correctly updated to use the CometBFT equivalentv11.ValidatorUpdate. This includes all list handling, method parameters, struct fields, and object initializations.Also applies to: 12207-12207, 12213-12213, 12218-12218, 12231-12231, 12424-12424, 12442-12442, 12642-12642, 14003-14003, 14026-14026, 14472-14472, 14496-14496
14051-14055: Protobuf schema updated to use CometBFT typesThe raw protobuf schema bytes have been updated to reference the new CometBFT package paths (
cometbft.types.v1andcometbft.abci.v1) instead of the previous Tendermint paths. This ensures consistency between the Go code and the underlying protobuf definitions.Also applies to: 14057-14064, 14391-14394
12814-12815: ValidatorUpdates struct definition updated correctlyThe
ValidatorUpdatesstruct has been properly updated to use CometBFT types. The migration follows the PR's objective of integrating CometBFT v1 into the Cosmos SDK codebase.Also applies to: 14391-14394
api/cosmos/autocli/v1/options.pulsar.go (2)
4501-4504: Plural-singular mismatch in struct field commentThe Go struct field is named
EnhanceCustomCommand, yet the associated comment block repeatedly uses the plural formenhance_custom_commands.
Tiny detail, but this can mislead devs and downstream doc-generators that rely on these comments.- // enhance_custom_commands specifies whether to skip the service when generating commands, if a custom command already - // exists, or enhance the existing command. If set to true, the custom command will be enhanced with the services from - // gRPC. otherwise when a custom command exists, no commands will be generated for the service. + // enhance_custom_command specifies whether to skip the service when generating commands if a custom command already + // exists, or enhance the existing command. If set to true, the custom command will be enhanced with the services from + // gRPC; otherwise, when a custom command exists, no commands will be generated for the service.[suggest_nitpick]
4816-4822:varargsvsoptionalmutual-exclusivity is only documented, not enforcedThe proto-comment says
optionalandvarargsare mutually exclusive, but the generated code (unsurprisingly) performs no validation.
If these descriptors are ever constructed programmatically (not only deserialized), an invalid combination could silently pass through and break the AutoCLI.Consider adding a small constructor / helper in non-generated code that validates
!(arg.Varargs && arg.Optional)(and possibly returns an error) before the CLI layer consumes it.Would you like a tiny helper + unit test snippet demonstrating this guard?
go.mod (2)
1-4: Confirm future Go toolchain versions are available in the build environmentThe file pins the module to
go 1.23.5and additionally specifiestoolchain go1.23.8.
Go 1.23 has not yet been released upstream (latest stable is 1.22). Please verify that:
- Your CI runners and downstream consumers have a compatible toolchain installed, or
- A custom fork/toolchain is published and referenced in your Docker images or
go.work.Otherwise
go mod download,go vet, etc. will fail outside of your internal environment.
24-26: Version-path mismatch between required and replaced CometBFT modulesYou
require:github.com/cometbft/cometbft v0.38.12 github.com/cometbft/cometbft/api v1.0.0and later override both with:
github.com/cometbft/cometbft => github.com/InjectiveLabs/cometbft v1.0.1-inj github.com/cometbft/cometbft/api => github.com/injectivelabs/cometbft/api v1.0.1-...Two things to double-check:
- The major version jump (
v0.38.x→v1.0.x) on the same import path is legal in Go modules but signals potentially breaking API changes. Ensure all SDK call-sites compile and behave at runtime.- The module paths differ in their casing / organisation (
InjectiveLabsvsinjectivelabs). Inconsistent casing can cache-poison module proxies and breakgo mod download.If the
requirestanza is no longer needed you can remove the legacyv0.38.12line and rely solely on thereplace—otherwisego mod tidywill keep re-adding it.Also applies to: 215-218
api/cosmos/staking/v1beta1/genesis.pulsar.go (2)
273-317: Generated list wrapper looks correct – only note about AppendMutable panicThe
_GenesisState_9_listwrapper is well-formed for arepeated stringfield;AppendMutableintentionally panics because scalar lists cannot return a mutable sub-message.
No action required.
459-465: Field wiring forallowed_delegation_transfer_receiversis consistent• Tag number 9 (0x4a) matches marshal/unmarshal logic.
• Reflection hooks (Range,Has,Set,Mutable,NewField) are updated.
• Getter added at line 1973.Everything aligns with protobuf-gen expectations.
Also applies to: 496-498, 699-703, 744-746
api/cosmos/store/streaming/abci/grpc.pulsar.go (4)
5-5: Confirm CometBFT v1 FinalizeBlock types integration
All references toFinalizeBlockRequestandFinalizeBlockResponsehave been updated across imports, struct fields, reflection methods (Set,Mutable,NewField), and getters. The mappings appear consistent and align with CometBFT v1’s API.Also applies to: 1883-1885, 189-191, 214-220, 233-240, 1907-1919
1128-1131: Confirm CometBFT v1 CommitResponse integration
All references toCommitResponseinListenCommitRequest—including struct field, reflection (Set,Mutable,NewField), and getter—are updated to the new CometBFT v1 type. This aligns with the overall migration.Also applies to: 1155-1158, 1183-1186, 1956-1958, 1987-1992
2117-2120: Verify goTypes references update
ThegoTypesslice now correctly includes pointers tov1.FinalizeBlockRequest,v1.FinalizeBlockResponse, andv1.CommitResponse. This ensures that the generated code references the proper CometBFT v1 message types.
2123-2126: Verify dependency index update
ThedepIdxsentries correctly map the new CometBFT v1 types (FinalizeBlockRequest,FinalizeBlockResponse,CommitResponse) in the service method definitions.api/cosmos/base/tendermint/v1beta1/types.pulsar.go (8)
5-6: Confirm protobuf import updates
Imports forcometbft/types/v1andcometbft/version/v1are correctly aliased asv1andv11respectively. This replaces the deprecated Tendermint protobuf package imports.
2009-2013: VerifyBlockstruct field updates
TheBlockstruct’sData,Evidence, andLastCommitfields are updated to use*v1.Data,*v1.EvidenceList, and*v1.Commit. This aligns with the CometBFT v1 API.
224-229: Check reflection methods forBlock
fastReflection_Block’sSet,Mutable, andNewFieldmethods correctly instantiate and type-assertv1.Data,v1.EvidenceList, andv1.Commit. All reflection paths align with the updated message types.Also applies to: 256-267, 286-293
2042-2061: Verify getters forBlock
TheGetData,GetEvidence, andGetLastCommitmethods correctly return the new CometBFT v1 types (*v1.Data,*v1.EvidenceList,*v1.Commit).
2070-2076: VerifyHeaderstruct field updates
TheHeaderstruct’sVersionandLastBlockIdfields are updated to*v11.Consensusand*v1.BlockID, replacing the old Tendermint types.
1043-1052: Check reflection methods forHeader
fastReflection_Header’sSet,Mutable, andNewFieldmethods now produce and assignv11.Consensusandv1.BlockIDas expected.Also applies to: 1092-1104, 1141-1153
2113-2146: Verify getters forHeader
TheGetVersionandGetLastBlockIdmethods correctly return the new CometBFT v1 types (*v11.Consensus,*v1.BlockID).
2322-2329: Validate goTypes and depIdxs for Tendermint v1beta1 types
ThegoTypesarray anddepIdxsmapping correctly includecometbft.types.v1.Data,EvidenceList,Commit,cometbft.version.v1.Consensus, andcometbft.types.v1.BlockID. This ensures the file references the new protobuf definitions throughout.Also applies to: 2330-2336
api/cosmos/base/abci/v1beta1/abci.pulsar.go (20)
5-6: Import replacements for CometBFT migration look correctThe imports have been updated to use CometBFT v1 protobuf packages instead of the legacy Tendermint packages, which is consistent with the PR objective of integrating CometBFT v1.
73-75: Type reference update to CometBFT EventThe list type has been correctly updated to use the new CometBFT Event type from the imported v1 package.
90-97: Consistent conversion to CometBFT EventThe interface conversion now correctly uses the new CometBFT Event type. This change is necessary to maintain type compatibility with the updated imports.
100-104: Proper update of AppendMutable with CometBFT EventThe new element instantiation is now using the CometBFT Event type, ensuring proper compatibility.
113-116: NewElement now returns CometBFT EventThe new element creation has been updated to return the proper CometBFT Event type.
526-530: Mutable list initialization updated to CometBFT EventsThis change properly initializes the empty Events list with the new CometBFT Event type.
590-592: NewField updated to use CometBFT EventsThe new field creation is correctly using the CometBFT Event type for list initialization.
3409-3457: Result event list wrapper now uses CometBFT EventsThe _Result_3_list struct now correctly works with CometBFT Event types. All related methods have been updated to handle the new type.
4095-4099: Unmarshal implementation updated for CometBFT EventsThe unmarshaling logic now correctly creates and appends CometBFT Event instances.
6536-6584: Updated SearchBlocksResult to use CometBFT Block typesAll list operations for the SearchBlocksResult.Blocks field have been updated to use the CometBFT Block type. This is consistent with the migration from Tendermint to CometBFT.
6856-6859: Mutable method updated for CometBFT BlocksThe Mutable method now correctly initializes the Blocks list with the CometBFT Block type.
6893-6895: NewField updated for CometBFT BlocksThe field creation now correctly uses the CometBFT Block type for list initialization.
7229-7232: Block unmarshaling now uses CometBFT BlockThe unmarshal implementation correctly appends new CometBFT Block instances to the list.
7322-7434: TxResponse definition updated with CometBFT Event referencesThe TxResponse struct now correctly references CometBFT Event types, maintaining consistency with the rest of the codebase migration.
7626-7697: Result struct updated with CometBFT Event typesThe Result struct definition and its accessor methods now correctly reference CometBFT Event types.
7942-8005: SearchBlocksResult updated with CometBFT Block typesThe SearchBlocksResult struct definition and accessors now correctly use CometBFT Block types.
8011-8022: Proto import paths updated to CometBFTThe raw proto descriptor has been updated to reference the CometBFT import paths instead of Tendermint.
8182-8183: Go type references properly updatedThe file_cosmos_base_abci_v1beta1_abci_proto_goTypes slice has been correctly updated to reference the CometBFT v1 types.
8188-8198: Dependency indices updated for CometBFT referencesThe dependency index mappings have been updated to correctly reference the CometBFT types.
1-8364: Comprehensive migration to CometBFT v1 completed successfullyThe file has been thoroughly updated to migrate from Tendermint to CometBFT v1. All type references, imports, and related code structures have been correctly updated. The changes are consistent and align with the PR objective of integrating CometBFT v1 into the Cosmos SDK.
These changes are purely related to updating type references and don't introduce any functional changes, which helps minimize the risk of introducing bugs during this migration.
api/cosmos/base/tendermint/v1beta1/query.pulsar.go (23)
3369-3372: Type swap looks correct
*types.BlockID→*v1.BlockIDand*types.Block→*v1.Blockfollow the CometBFT v1 migration plan. Casts are safe because both are protobuf-generated pointer types.
No issues spotted here.
3396-3402: Lazy allocation logic still valid after type changeThe
nilcheck +new(v1.BlockID)/new(v1.Block)pattern keeps the previous behaviour intact.
Good catch making sure the new types are allocated the same way.
3423-3427: Nothing to flag – constructor now instantiates the proper CometBFT types.
3661-3664:x.BlockId = &v1.BlockID{}switch looks fine; no regression.
3697-3700: Same as above forBlock, migration is correct.
4318-4321: Assignments updated to CometBFT types are correct.
4345-4351: Lazy allocation for latest-block response correctly updated.
4372-4376: Constructor path OK with new types.
4611-4614: No problems – unmarshalling intov1.BlockIDpointer is correct.
4647-4650: No problems – unmarshalling intov1.Blockpointer is correct.
6018-6020:DefaultNodeInfoupdated to CometBFT p2p v1 – change looks good.
6043-6045: Lazy allocation matches new type. LGTM.
6065-6067: Constructor updated – correct.
6283-6285: Unmarshal branch migrated without issues.
10690-10693: Struct field tags and comments updated – OK.
10717-10727: Getter methods now return the CometBFT types; signatures compile.
10771-10775: Same pattern for latest-block response – looks fine.
10798-10808: Getter methods fine.
10915-10917:DefaultNodeInfofield type updated – OK.
10939-10942: Getter method updated – no issues.
11682-11686: Dependency index array now references new CometBFT types – mapping looks correct.
11695-11703: All dep-index remaps verify the new positions; protobuf registration should succeed.
11367-11644: (The giant raw-descriptor blob was regenerated; no manual review needed.)baseapp/baseapp.go (1)
930-937: Potential decode duplication when caller already passedsdk.TxInside
runTxyou decode whentx == nil.
However, if the caller did supply a non-nilsdk.Txbut the value is malformed (e.g. not matchingtxBytesdue to a bug upstream), the state machine proceeds silently with the wrong transaction.Consider always computing the hash from
txBytes(source of truth) and, whentx != nil, validating equality as suggested above. This keeps a single decoding source of truth.api/cosmos/consensus/v1/tx.pulsar.go (1)
1291-1304: Adding new parameters requires updated validation & migration logic
MsgUpdateParamsnow carries two extra pointers (Synchrony,Feature, tags 6/7).
The proto generation is fine, but remember:
x/consensusmessage validation (usually inkeeper/msg_server_update_params.goor similar) must now enforceSynchrony != nil && Feature != nil, otherwise the “NOTE: All parameters must be supplied” comment becomes stale.Existing callers/tests that constructed the message without these fields will now fail at runtime once validation is tightened. Provide default construction helpers or bump
proto3_optionalwhere appropriate.Genesis & upgrade handlers that persist consensus params must be amended so that these two fields are initialised, otherwise chain start-up will panic when params are deserialised.
Please verify downstream code paths.
| module cosmossdk.io/api | ||
|
|
||
| go 1.20 | ||
| go 1.23.5 |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify Go version compatibility
The Go version has been updated to 1.23.5, which seems unusually high as the latest stable Go version at the time of this review is 1.22.x.
🌐 Web query:
What is the latest stable version of Go?
💡 Result:
The latest stable version of Go is 1.24.2, which was released on April 1, 2025[4]. This is the second minor revision of the Go 1.24 major release, which was initially released on February 11, 2025[2].
Go 1.24.2 includes security fixes to the net/http package as well as bug fixes to the compiler, the runtime, the go command, and several other packages including crypto/tls, go/types, net/http, and testing[2].
Go follows a predictable release schedule, with major versions released approximately every six months[6]. The previous major release, Go 1.23, was released six months before Go 1.24[3]. Go's versioning format follows the pattern go1.[major].[patch], where unlike most software, the second number (24 in this case) is considered the major version number[4].
Go maintains a strong commitment to backward compatibility, as stated in the Go 1 promise. All versions through the current Go 1.24 release have maintained this promise of compatibility[4], ensuring that programs written for earlier versions of Go continue to work with newer releases.
Citations:
- 1: https://go.dev/dl/
- 2: https://go.dev/doc/devel/release
- 3: https://tip.golang.org/doc/go1.24
- 4: https://en.wikipedia.org/wiki/Go_(programming_language)
- 5: https://github.com/golang/tools/releases
- 6: https://antonz.org/which-go/
- 7: https://tip.golang.org/doc/go1.23
Update Go version to latest stable (1.24.2)
The go directive in api/go.mod has been set to 1.23.5, but the current stable release is 1.24.2 (April 1, 2025) which includes security and bug fixes across net/http, crypto/tls, the compiler/runtime, and more.
• File: api/go.mod
Line 3: change
- go 1.23.5
+ go 1.24.2This ensures you’re on the latest supported Go version.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| go 1.23.5 | |
| go 1.24.2 |
| precommiter sdk.Precommiter // logic to run during commit using the deliverState | ||
| checkTxHandler sdk.CheckTxHandler | ||
|
|
||
| addrPeerFilter sdk.PeerFilter // filter peers by address and port |
There was a problem hiding this comment.
🛠️ Refactor suggestion
checkTxHandler field is declared but never referenced
The new checkTxHandler sdk.CheckTxHandler attribute is added to BaseApp, yet there is no read or write access to it in this file (nor in the provided diff). Carrying an unused pointer:
- wastes memory,
- risks confusing future readers (“is this actually hooked-up?”), and
- may break invariants if someone calls the setter after the app is sealed.
If the handler is wired-up in a different file, please verify and add a short comment here that points to the relevant logic.
Otherwise, either:
- checkTxHandler sdk.CheckTxHandler
+ // checkTxHandler optionally overrides the default CheckTx logic.
+ // It is nil until SetCheckTxHandler is invoked in options.go.
+ checkTxHandler sdk.CheckTxHandlerand ensure it is actually invoked, or drop the field for now.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| precommiter sdk.Precommiter // logic to run during commit using the deliverState | |
| checkTxHandler sdk.CheckTxHandler | |
| addrPeerFilter sdk.PeerFilter // filter peers by address and port | |
| precommiter sdk.Precommiter // logic to run during commit using the deliverState | |
| // checkTxHandler optionally overrides the default CheckTx logic. | |
| // It is nil until SetCheckTxHandler is invoked in options.go. | |
| checkTxHandler sdk.CheckTxHandler | |
| addrPeerFilter sdk.PeerFilter // filter peers by address and port |
| return &abci.CheckTxResponse{ | ||
| GasWanted: int64(gInfo.GasWanted), // TODO: Should type accept unsigned ints? | ||
| GasUsed: int64(gInfo.GasUsed), // TODO: Should type accept unsigned ints? | ||
| Log: result.Log, | ||
| Data: result.Data, | ||
| Events: sdk.MarkEventsToIndex(result.Events, app.indexEvents), | ||
| }, nil |
There was a problem hiding this comment.
🛠️ Refactor suggestion
CheckTx success path drops Code/Codespace – return full ABCI metadata
When runTx succeeds, the response lacks Code, Codespace, Info and other metadata contained in result:
return &abci.CheckTxResponse{
GasWanted: int64(gInfo.GasWanted),
GasUsed: int64(gInfo.GasUsed),
Log: result.Log,
Data: result.Data,
Events: sdk.MarkEventsToIndex(result.Events, app.indexEvents),
}, nilIf an AnteHandler returns a non-zero Code (e.g. a soft failure) or populates Codespace/Info, that information is silently discarded, making debugging and client UX harder.
return &abci.CheckTxResponse{
- GasWanted: int64(gInfo.GasWanted),
- GasUsed: int64(gInfo.GasUsed),
- Log: result.Log,
- Data: result.Data,
- Events: sdk.MarkEventsToIndex(result.Events, app.indexEvents),
+ Code: result.Code,
+ Codespace: result.Codespace,
+ Info: result.Info, // optional but useful
+ GasWanted: int64(gInfo.GasWanted),
+ GasUsed: int64(gInfo.GasUsed),
+ Log: result.Log,
+ Data: result.Data,
+ Events: sdk.MarkEventsToIndex(result.Events, app.indexEvents),
}, nilReturning the full set of fields keeps behaviour consistent with Cosmos-SDK <= 0.47 and avoids losing valuable diagnostics.
There was a problem hiding this comment.
Actionable comments posted: 4
🔭 Outside diff range comments (2)
baseapp/oe/optimistic_execution.go (1)
128-134:⚠️ Potential issueGuard against
niloe.requestto avoid panics in early-abort paths
AbortIfNeededassumesoe.requestis always set, but the method can be called beforeExecuteor after aReset, leavingoe.request == nil.
Accessingoe.request.Hashin that state will dereference anilpointer and crash the process.oe.mtx.Lock() defer oe.mtx.Unlock() - if !bytes.Equal(oe.request.Hash, reqHash) { + if oe.request == nil { + return false + } + if !bytes.Equal(oe.request.Hash, reqHash) {This low-cost check preserves existing behaviour when OE is inactive while eliminating a potential critical runtime panic.
baseapp/abci.go (1)
218-226:⚠️ Potential issueUsing the address of a loop variable creates duplicate pointers
abciSnapshotis a loop-scoped variable; taking its address (&abciSnapshot) on each
iteration appends multiple pointers that all reference the same memory slot.
After the loop finishes every element inresp.Snapshotswill point to the last
snapshot, silently corrupting the response.-for _, snapshot := range snapshots { - abciSnapshot, err := snapshot.ToABCI() - ... - resp.Snapshots = append(resp.Snapshots, &abciSnapshot) -} +for _, snapshot := range snapshots { + s, err := snapshot.ToABCI() + if err != nil { + ... + } + ss := s // create a new instance per iteration + resp.Snapshots = append(resp.Snapshots, &ss) +}Failing to fix this will cause peers to receive an invalid snapshot manifest and
abort state-sync.
🧹 Nitpick comments (12)
client/v2/CHANGELOG.md (1)
84-84: Unrelated changelog entry for AutoCLI enhancementThis changelog entry adds documentation for a feature to override short descriptions in AutoCLI-generated commands. While well-formatted, it appears unrelated to the stated PR objective of CometBFT v1 integration. Consider including this change in a separate PR focused on AutoCLI improvements for better traceability.
docs/docs/learn/advanced/00-baseapp.md (1)
435-435: Documentation updated to reflect new API type name.The parameter type has been correctly updated from the Tendermint
RequestInitChainto the CometBFT v1InitChainRequest, ensuring consistency with the code changes.You might also consider rewording "in order to initialize" to "to initialize" for improved conciseness.
🧰 Tools
🪛 LanguageTool
[style] ~435-~435: Consider a shorter alternative to avoid wordiness.
Context: ...tomy.md#initchainer) of the application in order to initialize the main state of the applic...(IN_ORDER_TO_PREMIUM)
client/grpc/cmtservice/service.go (1)
256-264: Consider updating function name to reflect CometBFT terminology.While the function works correctly with the new types, the name
RegisterTendermintServicestill uses the old "Tendermint" terminology rather than "CometBFT".-// RegisterTendermintService registers the CometBFT queries on the gRPC router. +// RegisterCometBFTService registers the CometBFT queries on the gRPC router. func RegisterTendermintService(While this is a minor issue, updating the function name would help maintain consistency with the terminology change throughout the codebase.
docs/docs/building-modules/10-autocli.md (3)
20-20: Refine wording: drop redundant “interface”
Use “CLI” instead of “CLI interface” to avoid acronym tautology.- This means that you can easily add a CLI interface to your application... + This means that you can easily add CLI to your application...🧰 Tools
🪛 LanguageTool
[style] ~20-~20: This phrase is redundant (‘I’ stands for ‘interface’). Use simply “CLI”.
Context: ...s. This means that you can easily add a CLI interface to your application without having to m...(ACRONYM_TAUTOLOGY)
28-28: Fix verb agreement
Change “specifies” to “specify” for grammatical correctness.- Use the `autocli.AppOptions` struct to specifies the modules you defined. + Use the `autocli.AppOptions` struct to specify the modules you defined.🧰 Tools
🪛 LanguageTool
[uncategorized] ~28-~28: This verb does not appear to agree with the subject. Consider using a different form.
Context: ... Use theautocli.AppOptionsstruct to specifies the modules you defined. If you are usi...(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
153-153: Avoid redundant phrasing: “CLI interfaces”
Replace “CLI interfaces” with “CLIs” for conciseness.- `autocli` is a powerful tool for adding CLI interfaces to your Cosmos SDK-based applications. + `autocli` is a powerful tool for adding CLIs to your Cosmos SDK-based applications.🧰 Tools
🪛 LanguageTool
[style] ~153-~153: This phrase is redundant (‘I’ stands for ‘interfaces’). Use simply “CLIs”.
Context: ...autocliis a powerful tool for adding CLI interfaces to your Cosmos SDK-based applications. ...(ACRONYM_TAUTOLOGY)
baseapp/oe/optimistic_execution.go (1)
90-99: Double-check field mapping betweenProcessProposalRequestandFinalizeBlockRequestThe new request is manually re-constructed. Most fields map 1-to-1, but the rename from
ProposedLastCommit→DecidedLastCommitis brittle and could break silently if CometBFT updates either side again.Consider:
- Adding an inline comment explaining the rename for future maintainers.
- Using a helper/convertor in
abci(if one exists) to future-proof this mapping.No functional change required now, just documentation or reuse of upstream helpers for maintainability.
baseapp/baseapp.go (4)
865-868: Comment still mentionsDeliverTx; update toFinalizeBlockThe explanatory block refers to “state is persisted iff … execution mode is DeliverTx”.
Since the ABCI v1 migration replacedDeliverTxwithFinalizeBlock, the wording can mislead future contributors.-// and execute successfully. State only gets persisted -// if all messages get executed successfully and the execution mode is DeliverTx. +// and execute successfully. State only gets persisted +// when all messages run successfully **and the execution mode is `execModeFinalize`** +// (i.e. during FinalizeBlock).
611-639:validateFinalizeBlockHeight– edge-case clarificationThe function now validates using:
if lastBlockHeight == 0 && app.initialHeight > 1 { … }This correctly handles genesis heights > 1, but keep in mind:
- If the chain is reset (export → import) and
initialHeightis bumped again,lastBlockHeightwill be non-zero and we’ll silently acceptlastBlockHeight+1. That is fine, but a short comment explaining the intent would help future readers.- Consider treating height
0explicitly in the error message; CometBFT will never deliver height 0 for FinalizeBlock, so returningabci.CodeTypeOKwith detailed log can aid node operators.No change required, just a doc comment could be useful.
756-784:beginBlockhook shares FinalizeBlockRequest – watch for accidental mutationBecause the same pointer
*abci.FinalizeBlockRequestis passed downstream, defensive code might accidentally mutate it (e.g.req.Txs = nil) and affect subsequent logic inFinalizeBlock.
Consider passing a copy (*req) when invoking external BeginBlocker handlers if any of them are not under your control.
1177-1180: Minor: error value can be dropped
runTxalready returns<_, _, _, err>; the interim assignment then immediately returns it.-_, _, _, err = app.runTx(execModePrepareProposal, bz, tx) -if err != nil { - return nil, err -} +if _, _, _, err = app.runTx(execModePrepareProposal, bz, tx); err != nil { + return nil, err +}Purely cosmetic.
baseapp/abci_utils.go (1)
235-242: Comment refers to obsolete field name in documentationThe docstring still references
PrepareProposalRequest.MaxBytes, but the new protobuf type exposes the field asMaxTxBytes. This can confuse downstream maintainers reading the comment.-// Enumeration is halted once PrepareProposalRequest.MaxBytes of transactions is +// Enumeration is halted once PrepareProposalRequest.MaxTxBytes of transactions is
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (30)
api/cosmos/staking/v1beta1/query_grpc.pb.gois excluded by!**/*.pb.goapi/cosmos/staking/v1beta1/tx_grpc.pb.gois excluded by!**/*.pb.goapi/go.sumis excluded by!**/*.sumapi/tendermint/abci/types_grpc.pb.gois excluded by!**/*.pb.goclient/grpc/cmtservice/query.pb.gois excluded by!**/*.pb.goclient/grpc/cmtservice/types.pb.gois excluded by!**/*.pb.gogo.sumis excluded by!**/*.sumorm/go.sumis excluded by!**/*.sumorm/internal/testpb/bank.pb.gois excluded by!**/*.pb.goorm/internal/testpb/bank_query.pb.gois excluded by!**/*.pb.goorm/internal/testpb/bank_query_grpc.pb.gois excluded by!**/*.pb.goorm/internal/testpb/test_schema.pb.gois excluded by!**/*.pb.goorm/internal/testpb/test_schema_query.pb.gois excluded by!**/*.pb.goorm/internal/testpb/test_schema_query_grpc.pb.gois excluded by!**/*.pb.goproto/buf.lockis excluded by!**/*.locksimapp/go.sumis excluded by!**/*.sumstore/go.sumis excluded by!**/*.sumstore/streaming/abci/grpc.pb.gois excluded by!**/*.pb.gostore/types/listening.pb.gois excluded by!**/*.pb.gotests/go.sumis excluded by!**/*.sumtypes/abci.pb.gois excluded by!**/*.pb.gotypes/tx/service.pb.gois excluded by!**/*.pb.gox/circuit/go.sumis excluded by!**/*.sumx/consensus/types/query.pb.gois excluded by!**/*.pb.gox/consensus/types/tx.pb.gois excluded by!**/*.pb.gox/evidence/go.sumis excluded by!**/*.sumx/feegrant/go.sumis excluded by!**/*.sumx/nft/go.sumis excluded by!**/*.sumx/staking/types/staking.pb.gois excluded by!**/*.pb.gox/upgrade/go.sumis excluded by!**/*.sum
📒 Files selected for processing (61)
CHANGELOG.md(1 hunks)api/cosmos/app/runtime/v1alpha1/module.pulsar.go(17 hunks)api/cosmos/autocli/v1/options.pulsar.go(29 hunks)api/cosmos/base/abci/v1beta1/abci.pulsar.go(27 hunks)api/cosmos/base/tendermint/v1beta1/query.pulsar.go(24 hunks)api/cosmos/base/tendermint/v1beta1/types.pulsar.go(21 hunks)api/cosmos/consensus/v1/query.pulsar.go(9 hunks)api/cosmos/consensus/v1/tx.pulsar.go(20 hunks)api/cosmos/staking/v1beta1/genesis.pulsar.go(16 hunks)api/cosmos/staking/v1beta1/staking.pulsar.go(18 hunks)api/cosmos/store/streaming/abci/grpc.pulsar.go(16 hunks)api/cosmos/store/v1beta1/listening.pulsar.go(11 hunks)api/cosmos/tx/v1beta1/service.pulsar.go(11 hunks)api/go.mod(1 hunks)api/tendermint/crypto/keys.pulsar.go(0 hunks)api/tendermint/libs/bits/types.pulsar.go(0 hunks)api/tendermint/types/block.pulsar.go(0 hunks)api/tendermint/types/validator.pulsar.go(0 hunks)api/tendermint/version/types.pulsar.go(0 hunks)baseapp/abci.go(31 hunks)baseapp/abci_test.go(91 hunks)baseapp/abci_utils.go(8 hunks)baseapp/abci_utils_test.go(7 hunks)baseapp/baseapp.go(10 hunks)baseapp/baseapp_test.go(27 hunks)baseapp/block_gas_test.go(2 hunks)baseapp/grpcrouter.go(3 hunks)baseapp/grpcrouter_helpers.go(1 hunks)baseapp/info.go(2 hunks)baseapp/msg_service_router_test.go(2 hunks)baseapp/oe/optimistic_execution.go(4 hunks)baseapp/oe/optimistic_execution_test.go(1 hunks)baseapp/options.go(1 hunks)baseapp/params.go(1 hunks)baseapp/params_legacy.go(1 hunks)baseapp/snapshot_test.go(9 hunks)baseapp/streaming_test.go(7 hunks)baseapp/test_helpers.go(4 hunks)baseapp/testutil/mock/mocks.go(1 hunks)baseapp/utils_test.go(1 hunks)client/grpc/cmtservice/block.go(1 hunks)client/grpc/cmtservice/service.go(2 hunks)client/grpc/cmtservice/types.go(1 hunks)client/grpc/cmtservice/util.go(1 hunks)client/grpc_query.go(1 hunks)client/grpc_query_test.go(1 hunks)client/query.go(5 hunks)client/rpc/block.go(1 hunks)client/rpc/rpc_test.go(1 hunks)client/rpc/tx.go(3 hunks)client/utils.go(1 hunks)client/v2/CHANGELOG.md(1 hunks)crypto/codec/amino.go(0 hunks)crypto/codec/cmt.go(1 hunks)crypto/keys/multisig/codec.go(0 hunks)docs/docs/build/abci/04-checktx.md(1 hunks)docs/docs/building-modules/10-autocli.md(1 hunks)docs/docs/learn/advanced/00-baseapp.md(2 hunks)docs/docs/learn/advanced/15-upgrade.md(1 hunks)go.mod(9 hunks)orm/go.mod(1 hunks)
💤 Files with no reviewable changes (7)
- crypto/codec/amino.go
- crypto/keys/multisig/codec.go
- api/tendermint/version/types.pulsar.go
- api/tendermint/libs/bits/types.pulsar.go
- api/tendermint/types/validator.pulsar.go
- api/tendermint/crypto/keys.pulsar.go
- api/tendermint/types/block.pulsar.go
👮 Files not reviewed due to content moderation or server errors (1)
- api/cosmos/tx/v1beta1/service.pulsar.go
🧰 Additional context used
🧬 Code Graph Analysis (10)
baseapp/options.go (2)
baseapp/baseapp.go (1)
BaseApp(67-209)types/abci.go (1)
CheckTxHandler(29-29)
baseapp/oe/optimistic_execution_test.go (3)
baseapp/abci_test.go (1)
TestOptimisticExecution(2357-2396)baseapp/oe/optimistic_execution.go (1)
NewOptimisticExecution(39-46)log/logger.go (1)
NewNopLogger(119-122)
baseapp/abci_utils_test.go (1)
types/abci.go (1)
PrepareProposalHandler(24-24)
client/grpc_query_test.go (1)
testutil/sims/app_helpers.go (1)
DefaultConsensusParams(36-51)
baseapp/oe/optimistic_execution.go (2)
client/grpc_query.go (1)
Context(125-127)server/cmd/execute.go (1)
Execute(19-35)
api/cosmos/staking/v1beta1/staking.pulsar.go (1)
x/staking/types/staking.pb.go (9)
Validator(349-378)Validator(382-382)Validator(383-385)HistoricalInfo(115-118)HistoricalInfo(122-122)HistoricalInfo(123-125)ValidatorUpdates(1204-1206)ValidatorUpdates(1210-1210)ValidatorUpdates(1211-1213)
api/cosmos/store/streaming/abci/grpc.pulsar.go (2)
store/streaming/abci/grpc.pb.go (6)
ListenFinalizeBlockRequest(33-36)ListenFinalizeBlockRequest(40-40)ListenFinalizeBlockRequest(41-43)ListenCommitRequest(123-128)ListenCommitRequest(132-132)ListenCommitRequest(133-135)api/cosmos/store/v1beta1/listening.pulsar.go (3)
StoreKVPair(1233-1242)StoreKVPair(1257-1257)StoreKVPair(1260-1262)
baseapp/streaming_test.go (2)
types/context.go (1)
Context(41-73)store/types/listening.pb.go (3)
StoreKVPair(31-36)StoreKVPair(40-40)StoreKVPair(41-43)
baseapp/abci_utils.go (2)
types/context.go (1)
Context(41-73)types/abci.go (4)
PrepareProposalHandler(24-24)ProcessProposalHandler(21-21)ExtendVoteHandler(32-32)VerifyVoteExtensionHandler(36-36)
api/cosmos/tx/v1beta1/service.pulsar.go (1)
types/tx/service.pb.go (3)
GetBlockWithTxsResponse(666-673)GetBlockWithTxsResponse(677-677)GetBlockWithTxsResponse(678-680)
🪛 LanguageTool
docs/docs/learn/advanced/00-baseapp.md
[style] ~435-~435: Consider a shorter alternative to avoid wordiness.
Context: ...tomy.md#initchainer) of the application in order to initialize the main state of the applic...
(IN_ORDER_TO_PREMIUM)
docs/docs/building-modules/10-autocli.md
[style] ~20-~20: This phrase is redundant (‘I’ stands for ‘interface’). Use simply “CLI”.
Context: ...s. This means that you can easily add a CLI interface to your application without having to m...
(ACRONYM_TAUTOLOGY)
[uncategorized] ~28-~28: This verb does not appear to agree with the subject. Consider using a different form.
Context: ... Use the autocli.AppOptions struct to specifies the modules you defined. If you are usi...
(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
[style] ~153-~153: This phrase is redundant (‘I’ stands for ‘interfaces’). Use simply “CLIs”.
Context: ...autocli is a powerful tool for adding CLI interfaces to your Cosmos SDK-based applications. ...
(ACRONYM_TAUTOLOGY)
🪛 GitHub Check: gosec
api/cosmos/staking/v1beta1/genesis.pulsar.go
[failure] 1339-1339: integer overflow conversion uint64 -> uint8
integer overflow conversion uint64 -> int
api/cosmos/autocli/v1/options.pulsar.go
[failure] 1484-1484: integer overflow conversion uint64 -> uint8
integer overflow conversion uint64 -> int
api/cosmos/app/runtime/v1alpha1/module.pulsar.go
[failure] 1518-1518: integer overflow conversion uint64 -> uint8
integer overflow conversion uint64 -> int
🔇 Additional comments (220)
CHANGELOG.md (1)
41-41: Clean addition of changelog entry for newCheckTxHandlerfeatureThe new changelog entry is well-formatted and correctly documents the addition of a
CheckTxHandlerin the baseapp component from PR cosmos#21979. This handler will allow extending the CheckTx logic, which is an important part of the CometBFT v1 integration.client/grpc/cmtservice/block.go (1)
6-6: Proper migration from Tendermint to CometBFT v1 import pathThe import path has been updated from Tendermint protobuf (
github.com/cometbft/cometbft/proto/tendermint/types) to the CometBFT v1 protobuf API (github.com/cometbft/cometbft/api/cometbft/types/v1). This is consistent with the PR objective to integrate CometBFT v1.client/grpc_query.go (1)
86-90: Updated ABCI query request type for CometBFT v1 compatibilityThe ABCI request type has been changed from
abci.RequestQuerytoabci.QueryRequestto align with CometBFT v1's ABCI protocol. The field structure remains identical, ensuring the functionality is preserved while adapting to the new type naming convention.client/rpc/block.go (1)
9-9: Updated import path to CometBFT v1 APIThe import path has been correctly updated from the deprecated Tendermint protobuf path to the new CometBFT v1 API path. This change aligns with the PR objective of integrating CometBFT v1.
baseapp/testutil/mock/mocks.go (1)
11-11: Updated crypto import to use CometBFT v1 APIThe crypto package import has been correctly updated to use the new CometBFT v1 API path. This ensures the mock implementations use the updated CometBFT crypto types while maintaining the same function signatures and behavior.
baseapp/params_legacy.go (1)
41-41: Updated cmtproto import to CometBFT v1 APIThe import path for consensus parameter types has been correctly updated to use the new CometBFT v1 API. Even though this file is marked as deprecated, this change ensures consistent usage of CometBFT types throughout the codebase during migration.
client/rpc/rpc_test.go (1)
97-102: Updated to use new QueryRequest typeThe test has been correctly updated to use the new
abci.QueryRequesttype instead of the deprecatedabci.RequestQuery. The field structure remains unchanged, preserving the test logic while ensuring compatibility with CometBFT v1.baseapp/utils_test.go (1)
16-16: Import path updated to CometBFT v1 protobuf types.The import for the
cmtprotopackage has been updated to use the new CometBFT v1 protobuf API path. This aligns with the broader migration from Tendermint to CometBFT v1 types across the codebase.crypto/codec/cmt.go (1)
4-4: Import path updated to CometBFT v1 crypto protobuf types.The import for the
cmtprotocryptopackage has been updated to use the new CometBFT v1 protobuf API path. This is consistent with the migration to CometBFT v1 types throughout the codebase.client/grpc/cmtservice/util.go (1)
4-4: Import path updated to CometBFT v1 protobuf types.The import for the
cmtprototypespackage has been updated to use the new CometBFT v1 protobuf API path. This change ensures compatibility with the latest CometBFT APIs while maintaining the same functionality.baseapp/params.go (1)
6-6: Import path updated to CometBFT v1 protobuf types.The import for the
cmtprotopackage has been updated to use the new CometBFT v1 protobuf API path. This change ensures theParamStoreinterface uses the latest ConsensusParams type definition from CometBFT v1.baseapp/grpcrouter_helpers.go (1)
48-48: Updated ABCI query type from RequestQuery to QueryRequest.The ABCI query type used in the
Invokemethod has been updated fromRequestQuerytoQueryRequestto align with the new CometBFT v1 ABCI type naming convention. This change is part of the broader migration to CometBFT v1 types.baseapp/msg_service_router_test.go (2)
153-153: API parameter type updated correctly.The code has been updated to use the new
abci.FinalizeBlockRequesttype instead of the deprecated Tendermint type. This change is consistent with the migration to CometBFT v1.
199-200: API parameter type updated correctly.The code has been updated to use the new
abci.FinalizeBlockRequesttype instead of the deprecated Tendermint type, maintaining the same functionality while adapting to the CometBFT v1 API.baseapp/options.go (1)
353-360: Good addition of CheckTxHandler setter.This new method follows the established pattern of BaseApp setter methods by:
- Checking if the app is sealed before allowing changes
- Using consistent error messaging with other setters
- Providing a clean extension point for custom CheckTx logic
This addition enhances the extensibility of the BaseApp, allowing applications to customize how transactions are checked, which is an important capability for the CometBFT v1 integration.
docs/docs/learn/advanced/00-baseapp.md (1)
207-207: Documentation updated to reflect new API type name.The parameter type has been correctly updated from the Tendermint
RequestInitChainto the CometBFT v1InitChainRequestto maintain consistency with the updated API.baseapp/block_gas_test.go (2)
118-122: API parameter type updated correctly.The test code has been updated to use the new
abci.InitChainRequesttype instead of the deprecated Tendermint type, properly aligning with the CometBFT v1 API changes.
158-158: API parameter type updated correctly.The test code has been updated to use the new
abci.FinalizeBlockRequesttype instead of the deprecated Tendermint type, ensuring compatibility with the CometBFT v1 API.client/grpc_query_test.go (2)
86-91: Updated to use the new CometBFT V1 request type.The code has been updated to use
InitChainRequestinstead of the deprecatedRequestInitChaintype, as part of the broader migration to CometBFT v1 ABCI types.
93-97: Updated to use the new CometBFT V1 request type.The code has been updated to use
FinalizeBlockRequestinstead of the deprecatedRequestFinalizeBlocktype, consistent with the CometBFT v1 migration.client/utils.go (1)
80-82:Details
❓ Verification inconclusive
Simplified RPC client initialization.
The explicit
/websocketpath argument has been removed from therpchttp.Newcall. This change aligns with updates in CometBFT's RPC client initialization patterns.
🏁 Script executed:
#!/bin/bash # Verify the signature of rpchttp.New in the CometBFT library rg -A 3 'func New\(' --type go | grep 'rpchttp'Length of output: 47
Double-check external
rpchttp.NewsignatureThe search didn’t locate the
rpchttp.Newdefinition in our local codebase (it lives in the external CometBFT module). Please verify that in the version you’re using, theNew(nodeURI string)call indeed defaults to"/websocket"and no longer requires an explicit path argument.• Confirm the import path (e.g.
github.com/cometbft/rpc/client/httpaliasrpchttp)
• Check theNewfunction signature in that module’s source or release notesbaseapp/info.go (3)
147-149: Updated embedded type to use new CometBFT V1 request type.The embedded type has been updated from
*abci.RequestPrepareProposalto*abci.PrepareProposalRequestas part of the CometBFT v1 migration.
161-163: Updated field reference to use new CometBFT V1 type.The code now accesses
ProposerAddressthrough the new field name structure.
165-167: Updated field reference to use new CometBFT V1 type.The code now accesses
LocalLastCommitthrough the new field name structure.baseapp/abci_utils_test.go (11)
9-10: Updated import paths for CometBFT V1 protobuf types.Import paths have been updated from the Tendermint-named paths (
github.com/cometbft/cometbft/proto/tendermint/*) to the new CometBFT V1 paths (github.com/cometbft/cometbft/api/cometbft/*).
498-499: Updated to use new CometBFT V1 request type.The test case struct now uses
*abci.PrepareProposalRequestinstead of the deprecated*abci.RequestPrepareProposaltype.
503-507: Updated test case to use new CometBFT V1 request type.Test case for "small max tx bytes" now initializes a
PrepareProposalRequestinstead of the deprecated request type.
515-519: Updated test case to use new CometBFT V1 request type.Test case for "small max gas" now initializes a
PrepareProposalRequestinstead of the deprecated request type.
523-527: Updated test case to use new CometBFT V1 request type.Test case for "large max tx bytes" now initializes a
PrepareProposalRequestinstead of the deprecated request type.
535-539: Updated test case to use new CometBFT V1 request type.Test case for "max gas and tx bytes" now initializes a
PrepareProposalRequestinstead of the deprecated request type.
618-619: Updated test struct to use new CometBFT V1 request type.The test struct now uses
*abci.PrepareProposalRequestinstead of the deprecated request type.
625-628: Updated test case to use new CometBFT V1 request type.The test case now initializes a
PrepareProposalRequestinstead of the deprecated request type.
633-636: Updated test case to use new CometBFT V1 request type.The test case now initializes a
PrepareProposalRequestinstead of the deprecated request type.
642-645: Updated test case to use new CometBFT V1 request type.The test case now initializes a
PrepareProposalRequestinstead of the deprecated request type.
652-656: Updated test case to use new CometBFT V1 request type.The test case now initializes a
PrepareProposalRequestinstead of the deprecated request type.client/rpc/tx.go (3)
26-26: Function rename improves consistency with CometBFT naming patternsThe function name has been updated from
newTxResponseCheckTxtonewTxCheckTxResponseto better align with CometBFT v1 naming conventions, where the entity type (TxCheckTx) comes before the action (Response).
85-86: Updated function call for renamed methodThis update correctly references the renamed function from line 26, maintaining consistency throughout the codebase.
122-122:Details
✅ Verification successful
Simplified RPC client initialization
The websocket path (
"/websocket") has been removed from the client initialization. This change aligns with CometBFT's client implementation which now handles the endpoint path internally.
🏁 Script executed:
#!/bin/bash # Search for other client instantiations to verify consistency rg "rpchttp.New\(" --type goLength of output: 217
RPC Client Initialization Simplified and Consistent
All
rpchttp.Newcalls now omit the explicit"/websocket"path, relying on CometBFT’s built-in handling:
- server/start.go:
rpcclient, err := rpchttp.New(svrCtx.Config.RPC.ListenAddress)- client/utils.go:
return rpchttp.New(nodeURI)- client/rpc/tx.go:
c, err := rpchttp.New(clientCtx.NodeURI)No further changes required—approving these updates.
baseapp/oe/optimistic_execution_test.go (2)
14-14: Updated ABCI type signatures for CometBFT v1Function signature now uses
*abci.FinalizeBlockRequestand*abci.FinalizeBlockResponsetypes instead of the legacy Tendermint-styleRequestFinalizeBlockandResponseFinalizeBlocktypes, aligning with CometBFT v1 naming conventions.
21-21: Updated ProcessProposal type for CometBFT v1The test now correctly uses the new
abci.ProcessProposalRequesttype instead of the legacyRequestProcessProposaltype, maintaining consistency with the rest of the codebase's migration to CometBFT v1 ABCI types.docs/docs/learn/advanced/15-upgrade.md (2)
106-106: Updated documentation with correct CometBFT v1 type namesThe documentation example for
InitChainerhas been correctly updated to useabci.InitChainRequestinstead of the deprecatedabci.RequestInitChaintype. This ensures developers following the documentation will use the correct type names that align with the CometBFT v1 naming conventions.
108-108: Setting module version map in InitChainer is essentialThe documentation correctly includes the important step of calling
app.UpgradeKeeper.SetModuleVersionMapwithin theInitChainerto persist module consensus versions at genesis. This is crucial for enabling proper in-place store migrations in future upgrades.baseapp/baseapp_test.go (2)
13-13: Updated import for CometBFT typesImport path has been updated to the new CometBFT v1 protobuf API, which aligns with the PR objective of integrating CometBFT v1.
101-102: Consistently updated ABCI request typesAll instances of deprecated ABCI request types have been properly migrated to their CometBFT v1 equivalents:
RequestFinalizeBlock→FinalizeBlockRequestRequestInitChain→InitChainRequestRequestQuery→QueryRequestThe changes maintain API consistency without altering test logic.
Also applies to: 106-107, 130-132, 165-169, 216-218, 227-228, 253-255, 260-262, 283-284, 368-371, 389-391, 398-401, 418-420, 527-530, 552-553, 582-586, 599-601, 616-619, 654-657, 667-670, 678-680, 694-697, 699-702, 721-725, 801-803, 861-865
baseapp/grpcrouter.go (2)
53-53: Updated GRPCQueryHandler type signatureThe handler type has been updated to use the new CometBFT query types, changing from
*abci.RequestQueryto*abci.QueryRequestand from*abci.ResponseQueryto*abci.QueryResponse.
106-128: Updated query handler implementationThe implementation of
registerABCIQueryHandlerhas been updated to use the new CometBFT ABCI types while preserving the same core logic. The function properly constructs aQueryResponseinstead of aResponseQuery.baseapp/test_helpers.go (2)
4-4: Updated import for CometBFT typesImport path has been updated to the new CometBFT v1 protobuf API, consistent with the changes in other files.
22-22: Updated runTx calls with additional transaction parameterThe calls to
runTxnow include the decoded transaction as an additional parameter, which helps avoid redundant transaction decoding. This optimization is consistent across all test helper functions.Also applies to: 28-28, 39-39, 50-50
client/grpc/cmtservice/types.go (2)
7-16: Renamed and updated conversion function for ABCI query requestsThe function has been renamed from
ToABCIRequestQuerytoToABCIQueryRequestand updated to return*abci.QueryRequestinstead of*abci.RequestQuery, aligning with the CometBFT v1 types.
18-20: Renamed and updated conversion function for ABCI query responsesThe function has been renamed from
FromABCIResponseQuerytoFromABCIQueryResponseand updated to accept*abci.QueryResponseinstead of*abci.ResponseQuery, maintaining consistency with the new CometBFT v1 types.orm/go.mod (6)
3-5: Go version and toolchain updates are appropriate for CometBFT v1 integration.The update to Go 1.23.0 and the explicit toolchain directive for Go 1.23.5 align with modern Go practices and ensure compatibility with the dependencies required for CometBFT v1.
12-12: Dependency update to cosmos-db correctly handles newer requirements.The upgrade from cosmos-db v1.0.2 to v1.1.1 is appropriate as part of the CometBFT v1 integration, ensuring compatibility with other updated components.
18-21: Core dependency versions updated appropriately.The upgrades to testify (v1.10.0) and protobuf (v1.36.5) are necessary to support the CometBFT v1 integration, particularly the newer protobuf types used throughout the codebase.
27-37: Appropriate updates to CockroachDB dependencies.These updates to CockroachDB-related packages, including the addition of the new fifo package, ensure compatibility with the cosmos-db upgrade and maintain database functionality.
58-63: Prometheus dependencies properly updated.The upgrades to Prometheus client libraries ensure monitoring compatibility with the updated codebase and dependencies.
65-67: Critical Go standard library dependencies updated.The updates to core golang.org/x packages (net, sys, and text) are essential for compatibility with the newer Go version and for security patches.
api/cosmos/consensus/v1/query.pulsar.go (10)
5-5: Import updated to use CometBFT types package.The change from Tendermint to CometBFT imports is a key part of the migration to CometBFT v1, correctly using the new package path
buf.build/gen/go/cometbft/cometbft/protocolbuffers/go/cometbft/types/v1.
530-530: Type reference updated to CometBFT ConsensusParams.The
Setmethod correctly converts the protoreflect value to the new CometBFT type*v1.ConsensusParams. This change is consistent with the migration from Tendermint to CometBFT types.
553-553: Mutable method updated for CometBFT consensus parameters.The allocation of a new instance now correctly uses
v1.ConsensusParamsinstead of the Tendermint equivalent, maintaining consistent type usage throughout the code.
570-570: NewField method properly uses the CometBFT type.The method correctly creates a new
v1.ConsensusParamsinstance, ensuring consistent type usage throughout the code.
767-767: UnmarshalInput properly initializes CometBFT types.The unmarshal function now correctly instantiates
v1.ConsensusParamsfor deserialization, maintaining consistent type usage.
859-859: Protobuf definition updated to reference CometBFT types.The struct field definition has been correctly updated to use the CometBFT type
*v1.ConsensusParamswith appropriate protobuf tags.
882-887: GetParams accessor method updated for CometBFT types.The getter method has been properly updated to return the CometBFT
*v1.ConsensusParamstype, ensuring type consistency throughout the API.
897-905: Raw descriptor properly updated for CometBFT import path.The protobuf raw descriptor bytes now correctly reference the CometBFT package path, ensuring proper serialization and deserialization.
944-946: Go type references correctly updated to CometBFT types.The file's type registry now properly lists the CometBFT
*v1.ConsensusParamstype in the interface mappings.
949-949: Dependency index updated for CometBFT consensus params.The dependency index correctly maps to the CometBFT types, ensuring proper message resolution during serialization/deserialization.
docs/docs/build/abci/04-checktx.md (5)
1-15: Well-structured introduction to CheckTx with clear visualization.The documentation provides an excellent introduction to the CheckTx process with a clear mermaid diagram showing the relationship between the user, CometBFT, and the Cosmos SDK components.
17-19: Good reference to implementation code.Linking directly to the implementation in the codebase is excellent practice, allowing developers to easily navigate between documentation and implementation.
21-27: Clear explanation of CheckTxHandler purpose and behavior.The documentation clearly explains the purpose of the
CheckTxHandlerand importantly notes the optimization of returning the decoded transaction to avoid redundant decoding.
29-31: Handler type definition is clear and concise.The Go type definition is presented clearly, showing the function signature that developers need to implement.
33-50: Implementation example aids developer adoption.The example code snippet showing how to integrate a custom CheckTxHandler in the application initialization is valuable for developers implementing this feature.
client/grpc/cmtservice/service.go (2)
28-28: ABCI query function type updated to use CometBFT types.The
abciQueryFntype alias has been correctly updated to use the new CometBFT ABCI types (*abci.QueryRequestand*abci.QueryResponse) instead of the deprecated Tendermint types.
249-253: ABCI Query implementation updated for CometBFT compatibility.The implementation now correctly:
- Uses
ToABCIQueryRequest()to convert the request to the new ABCI format- Returns the response using
FromABCIQueryResponse(res)to convert from the new formatThis ensures proper handling of the updated CometBFT ABCI types.
baseapp/streaming_test.go (8)
9-9: Import path updated to use CometBFT v1 APIThe import path has been correctly updated from the deprecated Tendermint proto path to the new CometBFT API path.
32-34: Method signature updated to use new CometBFT ABCI typesThe
ListenFinalizeBlockmethod signature has been correctly updated to use the newFinalizeBlockRequestandFinalizeBlockResponsetypes instead of the deprecated Tendermint request/response types.
36-39: Method signature updated to use new CometBFT ABCI typesThe
ListenCommitmethod signature has been correctly updated to use the newCommitResponsetype instead of the deprecated Tendermint response type.
54-58: InitChain call updated to use new CometBFT ABCI typeThe
InitChaincall has been correctly updated to useInitChainRequestinstead of the deprecated Tendermint request type.
72-73: FinalizeBlock call updated to use new CometBFT ABCI typeThe
FinalizeBlockcall has been correctly updated to use the new CometBFT ABCI request type.
97-98: FinalizeBlock call updated to use new CometBFT ABCI typeThe second
FinalizeBlockcall in the test has been correctly updated to use the new CometBFT ABCI request type.
122-124: InitChain call updated to use new CometBFT ABCI typeThe
InitChaincall in the second test function has been correctly updated to use the new CometBFT ABCI request type.
136-137: FinalizeBlock call updated to use new CometBFT ABCI typeThe
FinalizeBlockcall in the second test has been correctly updated to use the new CometBFT ABCI request type.client/query.go (6)
51-57: Function documentation and signature updated to use new CometBFT ABCI typesThe
QueryABCIfunction has been correctly updated to use the newQueryRequestandQueryResponsetypes instead of the deprecatedRequestQueryandResponseQuerytypes. This includes both the function signature and the documentation comment.
79-83: Method signature and error return updated to use new CometBFT ABCI typesThe
queryABCImethod signature and error return value have been correctly updated to use the newQueryRequestandQueryResponsetypes.
100-101: Error return updated to use new CometBFT ABCI typeThe error return in the
queryABCImethod has been correctly updated to use the newQueryResponsetype.
104-105: Error handling updated to use new CometBFT ABCI typeThe error handling in the
queryABCImethod has been correctly updated to use the newQueryResponsetype.
115-126: Error conversion function updated to use new CometBFT ABCI typeThe
sdkErrorToGRPCErrorfunction signature has been correctly updated to use the newQueryResponsetype, while maintaining the same error conversion logic.
132-137: Query method updated to use new CometBFT ABCI typeThe
querymethod has been correctly updated to use the newQueryRequesttype when callingqueryABCI.go.mod (6)
1-3: Go version updatedThe Go version has been updated to 1.23.5 with a toolchain directive for 1.23.8. This ensures compatibility with the latest supported Go version.
25-25: CometBFT API dependency updated to v1.0.0The CometBFT API dependency has been correctly updated to version 1.0.0, which is required for the CometBFT v1 migration.
33-34: Core dependencies updatedMultiple core dependencies have been updated to newer versions, including crypto libraries, testing utilities, metrics, CLI tools, and gRPC/protobuf libraries. These updates are necessary to maintain compatibility with the updated CometBFT v1 API.
Also applies to: 36-37, 52-57, 61-67
74-75: New Buf-generated protobuf dependencies addedNew dependencies on Buf-generated protobuf packages for CometBFT and Cosmos have been added, which are required for the CometBFT v1 protobuf types.
200-201: API replacement directive updatedThe replacement directive for cosmossdk.io/api has been updated to use a local path, ensuring consistency with the local modifications.
215-217: CometBFT replacement directives updatedThe replacement directives for CometBFT have been updated to use InjectiveLabs forks (v1.0.1-inj) that include Mempool lanes and DOG (Data Ordering Gateway) features. This is consistent with the PR objective of integrating CometBFT v1 into the Cosmos SDK for the Injective implementation.
baseapp/snapshot_test.go (11)
26-27: ListSnapshots request and response types updated to CometBFT v1The ListSnapshots API call has been correctly updated to use the new
ListSnapshotsRequestandListSnapshotsResponsetypes from CometBFT v1.Also applies to: 36-39
125-126: ListSnapshots request and response types updated in test caseThe ListSnapshots API call in the test case iterations has been correctly updated to use the new CometBFT v1 types.
Also applies to: 135-136
153-156: Query request type updated to CometBFT v1The Query API calls have been correctly updated to use the new
QueryRequesttype from CometBFT v1.Also applies to: 159-162
198-205: LoadSnapshotChunk request and response types updated to CometBFT v1The LoadSnapshotChunk API call has been correctly updated to use the new
LoadSnapshotChunkRequestandLoadSnapshotChunkResponsetypes from CometBFT v1.
231-246: OfferSnapshot result enum constants updated to CometBFT v1The OfferSnapshot result enum constants have been correctly updated to use the new naming convention in CometBFT v1 (e.g.,
OFFER_SNAPSHOT_RESULT_REJECTinstead of the deprecatedResponseOfferSnapshot_REJECT).
250-253: OfferSnapshot request and response types updated to CometBFT v1The OfferSnapshot API calls have been correctly updated to use the new
OfferSnapshotRequestandOfferSnapshotResponsetypes from CometBFT v1, along with the updated result enum constants.Also applies to: 257-266, 267-275
298-305: ListSnapshots request updated in snapshot restoration testThe ListSnapshots API call in the snapshot restoration test has been correctly updated to use the new
ListSnapshotsRequesttype from CometBFT v1.
307-310: OfferSnapshot request and response types updated in snapshot restoration testThe OfferSnapshot API call in the snapshot restoration test has been correctly updated to use the new CometBFT v1 types and result enum constants.
313-323: ApplySnapshotChunk request and response types updatedThe ApplySnapshotChunk API call has been correctly updated to use the new
ApplySnapshotChunkRequestandApplySnapshotChunkResponsetypes from CometBFT v1, along with the updated result enum constants.
327-334: LoadSnapshotChunk request updated in chunk application loopThe LoadSnapshotChunk API call in the chunk application loop has been correctly updated to use the new
LoadSnapshotChunkRequesttype from CometBFT v1.
335-342: ApplySnapshotChunk request and response types updated in chunk application loopThe ApplySnapshotChunk API call in the chunk application loop has been correctly updated to use the new CometBFT v1 types and result enum constants.
api/cosmos/store/v1beta1/listening.pulsar.go (5)
5-5: Import updated to CometBFT v1 ABCI types
The import aliasv1now points tobuf.build/gen/go/cometbft/cometbft/protocolbuffers/go/cometbft/abci/v1, aligning with the new CometBFT v1 protobuf definitions.
1299-1301: Migrate BlockMetadata struct fields to CometBFT v1 types
FieldsResponseCommit,RequestFinalizeBlock, andResponseFinalizeBlockare now typed to the newv1.CommitResponse,v1.FinalizeBlockRequest, andv1.FinalizeBlockResponserespectively. This matches the updated ABCI API.
809-813: UpdateSetmethod to assign CometBFT v1 messages
The setter cases correctly cast to the new v1 message types (*v1.CommitResponse,*v1.FinalizeBlockRequest,*v1.FinalizeBlockResponse). This ensures type safety when reflecting fields.
836-847: Lazy initialization of v1 messages inMutable
Within theMutableswitch, each field is lazily allocated as a new v1 message (new(v1.CommitResponse), etc.), preserving behavior while using the updated types.
863-870: Construct new v1 message instances inNewField
TheNewFieldimplementation now returns properly initialized v1 message wrappers for each of the three fields. This aligns with the reflection API’s expectations.docs/docs/building-modules/10-autocli.md (1)
1-3: Front-matter is standard YAML and requires no changes.api/cosmos/staking/v1beta1/staking.pulsar.go (18)
5-6: CometBFT import aliases are correctly applied.
The new imports forcometbft/abci/v1(aliased asv11) andcometbft/types/v1(aliased asv1) replace the deprecated Tendermint packages without conflicts in the import block.
249-251: HistoricalInfo.Set now uses the correct CometBFTHeadertype.
Assigningvalue.Message().Interface().(*v1.Header)properly maps the incoming protobuf field to the newv1.Header.
276-278: fastReflection_HistoricalInfo.Get initializes the newHeadercorrectly.
The nil-check andnew(v1.Header)allocation align with the updated CometBFTHeadertype.
300-301: fastReflection_HistoricalInfo.NewField returns a CometBFTHeaderinstance.
Creatingm := new(v1.Header)and wrapping it in aValueOfMessageis consistent with the new type.
521-523: Unmarshal logic correctly initializes the CometBFTHeader.
The checkif x.Header == nil { x.Header = &v1.Header{} }ensures the newHeaderis ready foroptions.Unmarshal.
12191-12192: ValidatorUpdates list wrapper now uses the CometBFTValidatorUpdatetype.
Defininglist *[]*v11.ValidatorUpdatealigns with the importedv11alias.
12207-12219: List methods correctly handlev11.ValidatorUpdate.
Set,Append, andAppendMutableall useInterface().(*v11.ValidatorUpdate)ornew(v11.ValidatorUpdate), ensuring consistency with CometBFT’s ABCI types.
12231-12233: NewElement for ValidatorUpdates returns a CometBFT message.
new(v11.ValidatorUpdate)andValueOfMessageare properly used.
12423-12425: fastReflection_ValidatorUpdates initializes the updates slice correctly.
Settingx.Updates = []*v11.ValidatorUpdate{}ensures a proper container for incoming values.
12442-12444: NewField for fastReflection_ValidatorUpdates uses the correct slice type.
Returningprotoreflect.ValueOfList(&_ValidatorUpdates_1_list{list: &list})matches the newv11.ValidatorUpdateelement type.
12642-12643: Unmarshal append logic uses the newv11.ValidatorUpdate.
Appending&v11.ValidatorUpdate{}before unmarshaling aligns with the changed protobuf definition.
12814-12816: HistoricalInfo struct fields updated to CometBFT types.
Header *v1.HeaderandValset []*Validatorcorrectly reflect the newv1import.
12838-12840: GetHeader returns the new CometBFTHeadertype.
The accessor now returns*v1.Header, consistent with struct changes.
14003-14004: ValidatorUpdates struct field uses the newValidatorUpdatetype.
DefiningUpdates []*v11.ValidatorUpdateupdates the type signature.
14026-14029: GetUpdates returns the updated slice type.
Accessor now returns[]*v11.ValidatorUpdate, matching the struct.
14051-14055: Raw descriptor imports reflect CometBFT package paths.
The byte metadata now referencescometbft/types/v1andcometbft/abci/v1, ensuring correct descriptor linkage.
14467-14473: Dependency index updated for CometBFT types.
Entries(*v1.Header)(nil)at index 23 and(*v11.ValidatorUpdate)(nil)at index 28 correctly map new types indepIdxs.
14496-14496: ValidatorUpdates.updates mapping now points to CometBFTValidatorUpdate.
Mapping to type index 28 (cometbft.abci.v1.ValidatorUpdate) aligns with the import change.api/cosmos/consensus/v1/tx.pulsar.go (1)
5-7: Generated file – no manual changes requiredThis file is fully generated by
protoc-gen-go-pulsar; the addedSynchronyandFeaturefields and the switch from Tendermint to CometBFT imports look mechanically correct. Ensure the generator is invoked in CI to avoid drift.api/cosmos/autocli/v1/options.pulsar.go (2)
671-678: Generated protobuf code – additions look correctThe new descriptors (
enhance_custom_command,short) are properly wired-in throughout reflection helpers (Range,Has,Get, …).
No action needed here – the file is fully generated, so manual edits should be avoided.Also applies to: 773-784
4816-4821:Details
✅ Verification successful
Missing validation for mutually-exclusive
optionalvsvarargs
PositionalArgDescriptornow documents thatoptionalandvarargsare mutually exclusive, but the runtime/API layer still accepts any combination of the two booleans.
While it is expected that higher-level AutoCLI code performs the validation, adding a small guard (e.g., in the CLI generation path) will prevent silent misconfiguration.// pseudo-code inside CLI generator, NOT in generated file if arg.Varargs && arg.Optional { return fmt.Errorf("positional arg cannot be both varargs and optional") }Please confirm that such a validation exists in the CLI-generation logic; if not, would you like assistance adding it?
Also applies to: 3988-3993, 4011-4015
🏁 Script executed:
#!/usr/bin/env bash # Search for where PositionalArgDescriptor is referenced in the CLI generator rg "PositionalArgDescriptor" -n . # Search for any runtime checks on Varargs/Optional fields rg "Varargs" -n . rg "Optional" -n .Length of output: 49297
🏁 Script executed:
#!/usr/bin/env bash # Inspect the Optional vs Varargs guard in the flag builder sed -n '130,180p' client/v2/autocli/flag/builder.goLength of output: 1403
Mutually-exclusive
optionalvsvarargsvalidation already in placeThe CLI-generation logic in
client/v2/autocli/flag/builder.go(lines 136–142) explicitly checks for and rejects anyPositionalArgDescriptorwhere bothOptionalandVarargsare set:if arg.Optional && arg.Varargs { return nil, fmt.Errorf("positional argument %s can't be both optional and varargs", arg.ProtoField) }No additional guard is needed in the generated code.
baseapp/baseapp.go (2)
930-937: Potential double-decode guard looks goodNice touch guarding redundant decoding by accepting an already-decoded
sdk.Tx.
This avoids an extra proto unmarshal whenPrepare/ProcessProposalVerifyTxcallrunTx.
734-754:preBlocknow receivesFinalizeBlockRequest– verify callers updatedSignature changes are sensible but please run
go vet ./...to ensure every internal call site (e.g. inabci.go) migrated to the new parameter list; mismatches compile successfully only ifinterface{}is used.api/cosmos/store/streaming/abci/grpc.pulsar.go (15)
5-5: Import updated to CometBFT v1 ABCI package
The import aliasv1now points tobuf.build/.../cometbft/abci/v1, aligning with the CometBFT v1 protobuf definitions.
189-191: Update type assertions in fastReflection Set to new v1 types
TheSetmethod forListenFinalizeBlockRequestnow casts values to*v1.FinalizeBlockRequestand*v1.FinalizeBlockResponse, matching the updated protobuf package.
213-220: Allocate new message instances with v1 types in fastReflection Mutable
TheMutablemethod correctly initializesnew(v1.FinalizeBlockRequest)andnew(v1.FinalizeBlockResponse)when fields are nil.
235-240: Create new fields with v1 types in fastReflection NewField
NewFieldnow returns message values wrapping newly allocatedv1.FinalizeBlockRequestandv1.FinalizeBlockResponse, consistent with the migration.
1879-1885: Update ListenFinalizeBlockRequest struct to use v1 types
The struct fieldsReqandResreferencev1.FinalizeBlockRequestandv1.FinalizeBlockResponse, replacing the deprecated Tendermint ABCI types.
1907-1919: Generate getters returning new v1 message types
MethodsGetReqandGetResnow return pointers to the updated CometBFT v1 message types.
1954-1958: Update ListenCommitRequest struct to use v1.CommitResponse
TheResfield inListenCommitRequestis now*v1.CommitResponse, consistent with the new ABCI v1 definitions.
1987-1992: Generate GetRes getter for ListenCommitRequest
TheGetResmethod correctly returns the new*v1.CommitResponsetype.
1127-1131: Update fastReflection Set for ListenCommitRequest
TheSetmethod now casts theResvalue to*v1.CommitResponse, aligning with the CometBFT v1 API.
1155-1160: Allocate new v1.CommitResponse in fastReflection Mutable
MutableforListenCommitRequestcorrectly initializesnew(v1.CommitResponse)whenResis nil.
1181-1186: Create new v1.CommitResponse in fastReflection NewField
NewFieldreturns a new message value wrappingnew(v1.CommitResponse), as expected for the migrated type.
453-455: Unmarshal logic allocates new v1.FinalizeBlockRequest
In the unmarshal branch for fieldReq, the code now allocates&v1.FinalizeBlockRequest{}before unmarshalling.
489-491: Unmarshal logic allocates new v1.FinalizeBlockResponse
In the unmarshal branch for fieldRes, the code allocates&v1.FinalizeBlockResponse{}prior to deserialization.
1432-1434: Unmarshal logic allocates new v1.CommitResponse
When unmarshallingListenCommitRequest, theResfield is now initialized with&v1.CommitResponse{}as intended.
2117-2119: Update goTypes mapping to include new v1 message types
Thefile_cosmos_store_streaming_abci_grpc_proto_goTypesslice now references*v1.FinalizeBlockRequest,*v1.FinalizeBlockResponse, and*v1.CommitResponse.api/cosmos/base/tendermint/v1beta1/types.pulsar.go (14)
5-6: Correctly updated imports to use CometBFT instead of TendermintThe import paths have been updated to reference CometBFT packages instead of the deprecated Tendermint packages, which aligns with the migration to CometBFT v1.
224-228: CometBFT types properly used in Block.Set methodThe field assignments in the Block.Set method have been correctly updated to use CometBFT types, maintaining the same functionality while migrating to the new package structure.
256-267: CometBFT types properly initialized in Block.Mutable methodThe field initializations in the Block.Mutable method have been correctly updated to use CometBFT types, ensuring consistent usage of the new package throughout the code.
286-293: CometBFT types properly created in Block.NewField methodThe field creation in the Block.NewField method has been correctly updated to use CometBFT types, maintaining consistency with the other changes in the file.
1044-1052: CometBFT types properly used in Header.Set methodThe field assignments in the Header.Set method have been correctly updated to use CometBFT types for version and block ID fields.
1093-1103: CometBFT types properly initialized in Header.Mutable methodThe field initializations in the Header.Mutable method have been correctly updated to use CometBFT types, maintaining consistency with the new package structure.
1142-1152: CometBFT types properly created in Header.NewField methodThe field creation in the Header.NewField method has been correctly updated to use CometBFT types, ensuring consistent usage of the new package.
1521-1644: CometBFT types properly initialized in Unmarshal functionThe field initializations in the Unmarshal function have been correctly updated to use CometBFT types, ensuring proper deserialization with the new package structure.
2009-2013: Block type definition properly updated to use CometBFT typesThe Block struct field types have been correctly updated to reference CometBFT types, maintaining the same structure while migrating to the new package.
2042-2061: Block getter methods properly updated to use CometBFT return typesThe return types in the Block getter methods have been correctly updated to reflect the CometBFT type system, ensuring API consistency.
2070-2075: Header type definition properly updated to use CometBFT typesThe Header struct field types for Version and LastBlockId have been correctly updated to use CometBFT type references.
2113-2146: Header getter methods properly updated to use CometBFT return typesThe return types in the Header getter methods have been correctly updated to use CometBFT types, ensuring API consistency throughout the codebase.
2220-2246: Protobuf definitions correctly updated to reference CometBFT proto filesThe protobuf imports and message field definitions have been properly updated to reference CometBFT proto files instead of Tendermint, maintaining compatibility with the new system.
2322-2336: Go type references and proto indices correctly updatedThe Go type references and protobuf message indices at the end of the file have been properly updated to reflect the CometBFT packages, ensuring consistency throughout the generated code.
api/cosmos/app/runtime/v1alpha1/module.pulsar.go (3)
389-434: New_Module_10_listwrapper is consistent with the existing pattern – looks goodThe helper type for
PreBlockersmirrors the structure of all earlier list wrappers (_Module_2_list … _Module_9_list). Length, (get|set|append|truncate) and validity checks all follow the same generated template, so the new field should work transparently with protobuf reflection.
1065-1073: gosec “integer overflow” warning is a false-positive for generated varint encoding
runtime.EncodeVarintintentionally casts lengths touint64before encoding; the generated marshal loop follows the same pattern for every string slice in this message. No action required.
2102-2106: Tag number10forpre_blockersis unique, but double-check the source.protoNothing in the existing message uses tag 10, so the wire format stays backward-compatible.
Please ensure the upstreammodule.protoschema was updated accordingly; otherwise a futureprotocrun would overwrite this file and lose the change.api/cosmos/base/abci/v1beta1/abci.pulsar.go (9)
4-6: Successful update of import paths to CometBFT v1The changes correctly replace Tendermint imports with their CometBFT v1 equivalents, ensuring compatibility with the new CometBFT blockchain protocol.
73-75: Type references updated appropriately to CometBFT EventThe list wrapper and methods are properly updated to use the CometBFT ABCI v1 Event type instead of the deprecated Tendermint Event type. This ensures correct type handling throughout the code.
Also applies to: 89-91, 95-97, 100-102, 113-115
526-528: CometBFT Event type initialization correctly implementedThe initialization of empty Event arrays has been properly migrated to use the CometBFT types, maintaining type safety throughout the codebase.
Also applies to: 590-592
1266-1268: Properly updated list append operations with CometBFT typesThe code correctly initializes and appends new instances of CometBFT types during unmarshaling operations, ensuring protocol compatibility.
Also applies to: 4094-4096, 7229-7230
7322-7322: Return type references successfully migratedThe getter functions now correctly return CometBFT types instead of Tendermint types, maintaining API compatibility while upgrading the underlying implementation.
Also applies to: 7429-7429, 7685-7686, 8000-8001
8015-8019: Proto import paths updated to CometBFTThe raw protobuf descriptor paths have been updated to reference CometBFT packages, ensuring correct serialization and deserialization of protocol messages.
8182-8184: Type reference mappings correctly updatedThe protobuf Go type mappings and dependency indices have been successfully migrated to CometBFT types, ensuring proper protobuf generation and consistency throughout the codebase.
Also applies to: 8188-8189, 8191-8192, 8198-8199
855-857: Block type references successfully updated to CometBFTThe code now correctly initializes Block arrays using CometBFT types instead of Tendermint types, maintaining API compatibility with the new CometBFT implementation.
Also applies to: 893-895
1-8364: Comprehensive migration to CometBFT v1 complete in this fileThis file demonstrates a thorough migration from Tendermint to CometBFT v1. The changes are purely related to import paths and type references, without altering functionality. This approach minimizes risk while ensuring compatibility with the new CometBFT implementation.
The implementation is consistent throughout the file, replacing all relevant Tendermint references with their CometBFT equivalents, which aligns perfectly with the PR objective of focusing exclusively on CometBFT v1-related updates.
api/cosmos/staking/v1beta1/genesis.pulsar.go (2)
273-318: NewAllowedDelegationTransferReceiverslist wrapper appears to be implemented correctlyThe
_GenesisState_9_listimplementation mirrors the patterns used by the preceding list wrappers (_GenesisState_3_list … _7_list).
All requiredprotoreflect.Listmethods are covered, and the panic inAppendMutable()is appropriate for a scalar (string) list.Looks good to me.
1892-1898: Double-check that the.protodefinition is committed and re-generated, not hand-editedA new repeated‐string field (tag
9) is added toGenesisState. Generated code should always be produced by the protobuf generator to ensure wire-compatibility and avoid divergence.Please confirm that:
cosmos/staking/v1beta1/genesis.protowas updated with
repeated string allowed_delegation_transfer_receivers = 9;- The file was re-generated via
buf generate,make proto, or the canonical generator command.If the change was applied manually to the generated
.gofile, re-generate instead; manual edits get silently overwritten on the next proto build.api/cosmos/base/tendermint/v1beta1/query.pulsar.go (24)
5-6: Correctly imported CometBFT v1 protobuf packages
The new aliasesv11(forcometbft/p2p/v1) andv1(forcometbft/types/v1) align precisely with the migration to CometBFT v1. These imports are used throughout this file.
3369-3371: Update fastReflection Set for GetBlockByHeightResponse
Assignments tox.BlockIdandx.Blocknow use the CometBFT v1 types (*v1.BlockID,*v1.Block), replacing the deprecated Tendermint types.
3396-3401: Initialize CometBFT v1 messages in fastReflection Get
The branches allocatenew(v1.BlockID)andnew(v1.Block)to ensure non-nil values for reflection. This correctly mirrors the updated protobuf definitions.
3423-3427: NewField instantiates CometBFT v1 protobuf messages
Usingnew(v1.BlockID)andnew(v1.Block)in theNewFieldmethod aligns with the migration and ensures correct message creation.
3661-3663: Pre-unmarshal allocation for CometBFT BlockID
Initializingx.BlockId = &v1.BlockID{}before callingoptions.Unmarshalprevents nil-pointer dereferences.
3697-3699: Pre-unmarshal allocation for CometBFT Block
Allocatingx.Block = &v1.Block{}matches the new protobuf type and ensures safe unmarshalling.
4318-4320: Update fastReflection Set for GetLatestBlockResponse
Assignments forx.BlockIdandx.Blockcorrectly switch to the CometBFT v1 types.
4343-4351: Initialize CometBFT v1 messages in GetLatestBlockResponse fastReflection Get
Theifchecks and allocations forBlockIdandBlockuse the updatednew(v1.BlockID)andnew(v1.Block)correctly.
4370-4377: NewField for GetLatestBlockResponse uses CometBFT types
Instantiations ofv1.BlockIDandv1.Blockare consistent across theNewFieldmethod.
4610-4612: Unmarshal CometBFT BlockID in GetLatestBlockResponse
Allocating&v1.BlockID{}before unmarshalling is correct and follows the same pattern as other responses.
4646-4648: Unmarshal CometBFT Block in GetLatestBlockResponse
Allocating&v1.Block{}prior tooptions.Unmarshalis appropriate and safe.
6017-6019: Update fastReflection Set for GetNodeInfoResponse
Assigningx.DefaultNodeInfoto*v11.DefaultNodeInfocorrectly updates the field to the CometBFT p2p v1 type.
6042-6045: Initialize CometBFT DefaultNodeInfo in fastReflection Get
The nil check and allocation ofnew(v11.DefaultNodeInfo)ensure proper message instantiation.
6064-6067: NewField for GetNodeInfoResponse uses CometBFT p2p types
Creatingnew(v11.DefaultNodeInfo)inNewFieldmatches the new proto definition.
6282-6284: Unmarshal CometBFT DefaultNodeInfo in GetNodeInfoResponse
Allocating&v11.DefaultNodeInfo{}before unmarshalling is correct to avoid nil pointer errors.
10690-10692: Struct fields updated to CometBFT v1 types
The fieldsBlockIdand the now-deprecatedBlockreference*v1.BlockIDand*v1.Block, in line with the migrated.proto.
10717-10727: Accessor methods updated for GetBlockByHeightResponse
GetBlockIdandGetBlocknow return the correct CometBFT v1 types without altering method semantics.
10771-10774: GetLatestBlockResponse struct fields updated
FieldsBlockIdand the deprecatedBlockare now typed to CometBFT v1 equivalents.
10798-10808: Accessor methods updated for GetLatestBlockResponse
The getters return*v1.BlockIDand*v1.Block, fully replacing the old Tendermint types.
10915-10917: GetNodeInfoResponse struct field updated
DefaultNodeInfonow uses*v11.DefaultNodeInfo, reflecting the updated protobuf import.
10939-10942: Accessor updated for GetDefaultNodeInfo
GetDefaultNodeInforeturns the new*v11.DefaultNodeInfotype correctly.
11370-11374: Raw descriptor updated with CometBFT proto paths
The gzipped descriptor now referencescometbft/p2p/v1/types.protoandcometbft/types/v1/types.proto, consistent with the migration.
11682-11686: Dependency slice includes CometBFT v1 types
Entries for(*v1.BlockID),(*v1.Block), and(*v11.DefaultNodeInfo)are correctly inserted into thefile_depslice.
11695-11702: Field dependency indexes updated for CometBFT types
Indexes forblock_id,block, anddefault_node_infomatch their positions in the updated dependency slice.baseapp/abci_test.go (20)
18-19: Updated import paths to use new CometBFT v1 API package structure.The code correctly imports the new protobuf packages from CometBFT v1's reorganized API structure.
49-49: Migrated ABCI type fromRequestInfotoInfoRequest.This correctly updates to the new CometBFT v1 ABCI message naming convention.
66-70: Updated ABCI InitChain request type and ConsensusParams reference.The code properly migrates from Tendermint types to CometBFT v1 equivalents, maintaining the same functionality while using the updated type signatures.
91-95: Updated InitChainer function signature to match new ABCI types.The InitChainer callback correctly uses the new
InitChainRequestandInitChainResponsetypes.
97-100: MigratedQueryRequesttype to match CometBFT v1 conventions.The code properly uses the updated type naming pattern.
140-144: Updated FinalizeBlock API with new request type.The code correctly uses the new CometBFT v1
FinalizeBlockRequesttype.
290-293: Updated ExtendVoteHandler signature to use new ABCI request/response types.The ExtendVote handler function correctly uses the new CometBFT v1 types.
295-303: Updated VerifyVoteExtensionHandler to use new types and enum values.The code correctly:
- Uses the new request/response types for vote extension verification
- Uses the proper enum constants (
VERIFY_VOTE_EXTENSION_STATUS_ACCEPT/REJECT) from the CometBFT v1 package
412-420: Consistent usage of CometBFT v1 enum values for vote extension verification.The code properly uses the updated enum patterns throughout the vote extension verification flow.
471-474: Updated AddrPeerFilter callback signature with new QueryResponse type.The filter callback correctly returns the new CometBFT v1 response type.
478-481: Updated IDPeerFilter callback signature with new QueryResponse type.The filter callback correctly returns the new CometBFT v1 response type.
580-584: Updated CheckTx API with new request type and enum constants.The code properly uses
CHECK_TX_TYPE_CHECKfrom the CometBFT v1 package.
1446-1447: Updated ProcessProposal response status enum constant.The code correctly uses the
PROCESS_PROPOSAL_STATUS_ACCEPTenum value from the CometBFT v1 package.
2032-2039: Updated PreBlocker callback signature to use new FinalizeBlockRequest type.The function correctly accepts the new CometBFT v1 request type and returns the appropriate response.
2087-2094: Updated ExtendVoteHandler to use new ABCI request/response types.The handler correctly implements the new CometBFT v1 message patterns.
2096-2105: Updated VerifyVoteExtensionHandler to use new ABCI types and constants.The handler correctly:
- Uses the new request/response types
- Uses the proper enum constants for verification status
2107-2126: Updated PrepareProposal callback to use new ABCI request/response types.The function correctly implements the CometBFT v1 signature with appropriate return types.
2128-2141: Updated ProcessProposal callback to use new ABCI types and constants.The function properly returns the new response type with the appropriate status constants from CometBFT v1.
2143-2165: Updated PreBlocker callback to use new ABCI FinalizeBlockRequest type.The function signature matches the expected CometBFT v1 pattern.
2456-2459: Updated CheckTx request with new type and enum constant.The code properly uses
CHECK_TX_TYPE_RECHECKfrom the CometBFT v1 package.
| go 1.23.5 | ||
|
|
||
| require ( | ||
| buf.build/gen/go/cometbft/cometbft/protocolbuffers/go v1.36.5-20241120201313-68e42a58b301.1 |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Added CometBFT v1 protobuf dependencies
These dependencies are necessary for the migration from Tendermint to CometBFT v1. The inclusion of direct and indirect dependencies on CometBFT and Cosmos protobuf definitions aligns with the PR objective of integrating CometBFT v1.
Also applies to: 11-11, 15-15
🏁 Script executed:
#!/bin/bash
# Check for any references to old Tendermint imports that might have been missed
rg "github.com/tendermint/" --type goLength of output: 954
Replace remaining Tendermint imports with CometBFT equivalents
The api/go.mod update correctly adds the CometBFT v1 protobuf dependency, but we’ve detected numerous lingering imports of github.com/tendermint/... that must be migrated to CometBFT packages to complete the migration:
• x/tx/signing/aminojson/time.go
• x/tx/signing/aminojson/json_marshal_test.go
• store/snapshots/manager.go
• testutil/testdata/codec.go
• fuzz/tests/tendermint_amino_decodetime_test.go
• crypto/ledger/ledger_secp256k1.go
• crypto/keys/multisig/amino.go
• codec/types/compat_test.go
• codec/types/compat.go
• codec/amino.go
Please update these to the appropriate github.com/cometbft/... imports (and likewise adjust the entries at lines 11 and 15 in api/go.mod) so the codebase no longer depends on Tendermint v0.x.
| module cosmossdk.io/api | ||
|
|
||
| go 1.20 | ||
| go 1.23.5 |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify Go version compatibility
The Go version has been updated to a very recent version (1.23.5). While using the latest version is generally good practice, ensure this version is sufficiently stable and that your CI/CD pipeline supports it.
🌐 Web query:
What is the latest stable Go version as of May 2025?
💡 Result:
Based on the search results, the latest stable Go version as of May 2025 is Go 1.24.2, which was released on April 1, 2025[1].
Go follows a regular release cycle with major versions released every six months[5]. The Go 1.24 series was initially released on February 11, 2025 (go1.24.0)[1], followed by minor revisions:
- Go 1.24.1 was released on March 4, 2025[1]
- Go 1.24.2 was released on April 1, 2025[1]
The minor revisions typically include security fixes and bug fixes. For Go 1.24.2 specifically, it includes security fixes to the net/http package, as well as bug fixes to the compiler, the runtime, the go command, and several packages including crypto/tls, go/types, net/http, and testing[1].
According to the release dashboard, Go 1.24.3 is in development but has not been officially released yet as of May 2025[7].
The next major version, Go 1.25, is expected to be released in August 2025[6], continuing the six-month release cycle that Go follows.
Citations:
- 1: https://go.dev/doc/devel/release
- 2: https://go.dev/dl/
- 3: https://tip.golang.org/doc/go1.24
- 4: https://github.com/golang/tools/releases
- 5: https://antonz.org/which-go/
- 6: https://tip.golang.org/doc/next
- 7: https://dev.golang.org/release
- 8: https://endoflife.date/go
- 9: https://discussion.fedoraproject.org/t/fedora-doesnt-provide-latest-version-of-go/146930
- 10: https://blog.jetbrains.com/research/2025/04/is-golang-still-growing-go-language-popularity-trends-in-2024/
Update or confirm Go version in api/go.mod
- Location:
api/go.mod:3(go 1.23.5) - As of May 2025, the latest stable Go release is 1.24.2 (April 1, 2025).
- Action required:
- Option A: Bump to
go 1.24.2to pick up the latest security and bug fixes. - Option B: If you stay on
go 1.23.5, ensure all CI/CD tools and environments fully support it.
- Option A: Bump to
| func (oe *OptimisticExecution) WaitResult() (*abci.FinalizeBlockResponse, error) { | ||
| <-oe.stopCh | ||
| return oe.response, oe.err | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Handle nil stopCh in WaitResult
WaitResult blocks on <-oe.stopCh. If the caller invokes WaitResult before Execute, stopCh is nil, causing an indefinite block.
A defensive check prevents accidental dead-locks during refactors or tests:
-func (oe *OptimisticExecution) WaitResult() (*abci.FinalizeBlockResponse, error) {
- <-oe.stopCh
+func (oe *OptimisticExecution) WaitResult() (*abci.FinalizeBlockResponse, error) {
+ if oe == nil || oe.stopCh == nil {
+ return nil, fmt.Errorf("optimistic execution not started")
+ }
+ <-oe.stopCh
return oe.response, oe.err
}(import "fmt" at top if not already present).
| checkTxHandler sdk.CheckTxHandler | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
checkTxHandler is declared but never referenced
The new checkTxHandler sdk.CheckTxHandler field is added to BaseApp, however I could not find any read or invocation sites in this file (nor in the rest of the diff).
If the intention is to provide an extension-point for custom CheckTx logic, forgetting to wire it means:
- external callers have no way to plug their handler,
- future refactors may silently drop the field as “dead code”.
Please ensure the handler is:
- Exposed via a
SetCheckTxHandlerpublic setter (similar to other hooks), and - Invoked from inside
(*BaseApp).CheckTxbefore the default logic runs (with a sane fallback whennil).
Otherwise, consider removing the field until the full feature is delivered to avoid confusing maintainers.
The PR contains the smallest* diff possible (only cometbftv1 related changes) and all** unit/e2e tests pass.
*Note: grpc/pulsar re-generated, but we missed that during #53 so it has additional methods for TransferDelegation stuff in the diff. Can be ignored.**orm tests are not relevant because module was deprecated & deleted some time agoFull diff without autogenerated code (8000 LOC):
https://gist.github.com/maxim-inj/2c9cbe3f079bc55eb4d917fede9bcd6f