feat(grpc): add earliest/latest block height to GetSyncing response #25648
+211
−94
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR extends the
GetSyncingResponseincosmos.base.tendermint.v1beta1.Serviceto include block height information that is essential for indexers and tooling.Problem
Indexers need to know which blocks are available on a node before attempting to fetch them. Currently, this information is only available via CometBFT's
/statusRPC endpoint (sync_info.earliest_block_height), requiring clients to query two different endpoints.When an indexer tries to fetch a pruned block, it gets an error like:
Discovering available block heights proactively via gRPC would be more efficient.
Solution
Add two new fields to
GetSyncingResponse:earliest_block_height- The earliest block height available on this nodelatest_block_height- The latest block height available on this nodeThese fields expose the same information as CometBFT's
SyncInfostruct, making it available via the existing gRPC endpoint without requiring a separate RPC call.Changes
proto/cosmos/base/tendermint/v1beta1/query.protoGetSyncingResponseclient/grpc/cmtservice/query.pb.goclient/grpc/cmtservice/service.goSyncInfoAPI
Backward Compatibility
This is a non-breaking change - it only adds new optional fields to an existing response message. Existing clients will continue to work unchanged.
Use Case