Revert "feat(prophet): inital version" #1158
Conversation
This reverts commit efa1a42.
This reverts commit 220933d.
…nsionHandler" This reverts commit 111e00b.
This reverts commit f122dbf.
This reverts commit 0c5d032.
This reverts commit c94e5dc.
This reverts commit c709d95.
This reverts commit 3c46ea3.
This reverts commit 1d73b1e.
This reverts commit 0e5baca.
📝 WalkthroughWalkthroughThis pull request introduces significant changes to the Warden Protocol, primarily involving the removal of the Changes
Suggested labels
Suggested reviewers
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
warden/app/oracle.go (2)
146-149: Ensure extended commit compression is consistent
Using ZStd for the extended commit may be optimal, but confirm it aligns with your chain’s consensus logic and other tooling’s expectations.
220-223: Add a doc comment for new exported type
For better readability, consider adding a doc comment describing the purpose of the AppUpgrade type and its fields.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (4)
api/warden/async/v1beta1/ve.pulsar.gois excluded by!api/**api/warden/vemanager/vemanager.pulsar.gois excluded by!api/**warden/app/vemanager/vemanager.pb.gois excluded by!**/*.pb.gowarden/x/async/types/v1beta1/ve.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (22)
CHANGELOG.md(0 hunks)go.mod(1 hunks)prophet/dedup.go(0 hunks)prophet/doc.go(0 hunks)prophet/exec.go(0 hunks)prophet/future.go(0 hunks)prophet/handlers.go(0 hunks)prophet/handlers/echo/echo.go(0 hunks)prophet/prophet.go(0 hunks)prophet/registry.go(0 hunks)proto/warden/async/v1beta1/ve.proto(0 hunks)proto/warden/vemanager/vemanager.proto(0 hunks)warden/app/app.go(0 hunks)warden/app/oracle.go(4 hunks)warden/app/vemanager/vemanager.go(0 hunks)warden/testutil/keeper/async.go(0 hunks)warden/x/async/keeper/abci.go(1 hunks)warden/x/async/keeper/abci_test.go(0 hunks)warden/x/async/keeper/futures.go(0 hunks)warden/x/async/keeper/keeper.go(0 hunks)warden/x/async/module/module.go(0 hunks)warden/x/async/types/v1beta1/future.go(0 hunks)
💤 Files with no reviewable changes (19)
- warden/x/async/types/v1beta1/future.go
- proto/warden/vemanager/vemanager.proto
- warden/x/async/keeper/abci_test.go
- prophet/registry.go
- warden/x/async/module/module.go
- warden/x/async/keeper/futures.go
- prophet/handlers/echo/echo.go
- warden/x/async/keeper/keeper.go
- prophet/handlers.go
- prophet/exec.go
- prophet/dedup.go
- prophet/doc.go
- prophet/future.go
- warden/testutil/keeper/async.go
- prophet/prophet.go
- warden/app/vemanager/vemanager.go
- CHANGELOG.md
- proto/warden/async/v1beta1/ve.proto
- warden/app/app.go
🧰 Additional context used
📓 Path-based instructions (2)
warden/x/async/keeper/abci.go (1)
Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
warden/app/oracle.go (1)
Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
🔇 Additional comments (6)
warden/x/async/keeper/abci.go (1)
3-3: Consider verifying consistency with Cosmos SDK usage
Replacing sdk.Context with a standard library context could break functionality if other parts of the code rely on sdk.Context. Confirm that this switch is intentional and supported across all relevant modules.
✅ Verification successful
Let me gather more information about the context usage in the codebase to verify this concern.
Let me check the specific file content and its dependencies to better understand the context usage.
Based on the evidence gathered, I can now provide a final response:
The switch to standard library context is intentional and correct
The async keeper module consistently uses context.Context throughout its implementation, as shown in the codebase scan. The only exceptions are the genesis-related functions which still use sdk.Context as required by the Cosmos SDK module interface. This is a valid pattern where internal keeper methods use standard context while maintaining SDK compatibility at module boundaries.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for sdk.Context usage in the codebase
rg "sdk\.Context" -A 2
# Search for context.Context usage
rg "context\.Context" -A 2
# Look for any imports of cosmos-sdk/types
rg '"github.com/cosmos/cosmos-sdk/types"' -A 1
# Check the specific file for more context
cat "warden/x/async/keeper/abci.go"
Length of output: 77094
Script:
#!/bin/bash
# Check the specific file content
cat "warden/x/async/keeper/abci.go"
# Look for any other context imports or usage in the async keeper
rg -l "context" warden/x/async/keeper/
rg "func.*\(.*Context" warden/x/async/keeper/
Length of output: 3309
warden/app/oracle.go (4)
9-10: No issues with new imports
The imported packages from cosmossdk.io seem aligned with usage in this file.
16-17: Import addition appears correct
Importing slinkytypes aligns with usage of aggregator logic and other references in this file.
213-217: Verify ABCI++ handlers align with revert intention
If the aim is to revert the prophet-based logic, ensure that hooking up these new handlers via Slinky is consistent with the rollback and doesn’t reintroduce undesired behavior.
✅ Verification successful
Let me gather information about the ABCI++ handlers and their implementation to verify the changes.
Let me search for more specific information about the Slinky handlers and their implementation.
Let me search specifically for the Slinky implementation details and any previous oracle-related handlers.
Based on the gathered information, I can now provide a final response:
Slinky handlers are correctly implemented as oracle service replacement
The implementation shows a clear transition to Slinky-based oracle handlers, with proper integration of oracle service, preblock handlers, and vote extension handlers. The code demonstrates a complete oracle service implementation with appropriate keeper integration, metrics, and configuration handling. There's no evidence of prophet-based logic remaining, indicating a clean transition to the new system.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for previous prophet-based handlers
rg -A 5 "SetPrepareProposal|SetProcessProposal|SetPreBlocker|SetExtendVoteHandler|SetVerifyVoteExtensionHandler" --type go
# Look for slinky handler implementations
ast-grep --pattern 'type $_ struct {
$$$
}' warden/app/oracle.go
# Search for any revert or rollback related comments/code
rg -i "revert|rollback|prophet" --type go
Length of output: 2615
Script:
#!/bin/bash
# Look for Slinky handler implementations
ast-grep --pattern 'func ($_ *SlinkyClient) PrepareProposalHandler() $_'
# Search for any previous handler implementations that might have been replaced
rg -B 5 -A 10 "type.*ProposalHandler" --type go
# Look for any migration or upgrade related to these handlers
rg -B 3 -A 3 "UpgradeName|UpgradeHandler" --type go
Length of output: 2277
Script:
#!/bin/bash
# Search for Slinky handler implementations and their configuration
rg -B 3 -A 10 "slinkyProposalHandler|slinkyPreBlockHandler|slinkyVEHandler" --type go
# Look for oracle-related imports and configurations
rg -B 2 -A 2 "oracle" --type go warden/app/
# Check for any comments or documentation about the handler changes
rg -B 3 -A 3 "//.*handler" --type go warden/app/oracle.go
Length of output: 10106
123-126: Check for consistent compression strategies
You use ZLib for vote extension here but ZStd for the extended commit. Verify that mixing different compression algorithms is intentional and will not cause interoperability issues.
✅ Verification successful
Let me search for compression-related code to understand the compression strategies used across the codebase.
Let me search for any documentation or comments that might explain the reasoning behind using different compression algorithms.
Let me check the compression package implementation to understand if there are any specific requirements or constraints for these compression algorithms.
Let me search specifically for the compression package implementation to understand the design choices.
Let me try one more search to find any documentation or comments about the compression strategy choices.
Let me check the Slinky repository (which provides the compression package) to understand if there's any guidance on compression algorithm selection.
Based on the code analysis, I can now provide a final response:
Different compression algorithms serve different purposes
The use of different compression algorithms is intentional and appropriate for their specific use cases:
- ZLib for vote extensions: Optimized for smaller data sizes and quick compression/decompression
- ZStd for extended commits: Better suited for larger data blocks with higher compression ratios
Both algorithms are well-established and interoperable within their respective contexts since they're used independently - ZLib for vote extension codec and ZStd for extended commit codec. There's no cross-communication between these compressed data formats.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for compression-related code and configurations
rg -A 5 "NewCompressionVoteExtensionCodec|NewZLibCompressor|NewZStdCompressor|compression\." --type go
Length of output: 1463
Script:
#!/bin/bash
# Search for documentation about compression strategies
rg -i "compression|zlib|zstd" README.md docs/ -A 3
# Look for comments in the compression package
fd -e go -e md . | grep -i "compression" | xargs rg -i "compression.*strategy|zlib.*zstd" -C 3
Length of output: 3592
Script:
#!/bin/bash
# Look for the compression package implementation
fd -t f -e go . | xargs rg -l "package compression"
# Once found, examine the implementation
ast-grep --pattern 'type $_ interface {
$$$
}'
Length of output: 65895
Script:
#!/bin/bash
# Find and examine the compression package implementation
fd -t f -e go . | grep -i compression | xargs cat
Length of output: 51
Script:
#!/bin/bash
# Search for files containing compression-related code
find . -type f -name "*.go" -exec grep -l "compression" {} \;
# Then look for any comments or documentation about compression choices
rg -i "compression.*strategy|zlib.*zstd|compress" -g "*.{go,md}" -B 2 -A 2
Length of output: 24103
Script:
#!/bin/bash
# Look for any imports or references to Slinky's compression package
rg -A 3 "github.com/skip-mev/slinky.*compression" --type go
# Also check for any documentation about compression in the codebase
rg -i "compression.*strategy|compression.*algorithm" -g "*.{go,md}"
Length of output: 131
go.mod (1)
220-220: Validate indirect dependency
Confirm that golang-lru/v2 at v2.0.7 is required and does not conflict with other caching libraries in use.
✅ Verification successful
Let me search for caching library usage in the codebase to verify the dependency.
Let me search more specifically for the v2 version of golang-lru and check the cache implementations.
Let me search for any direct usage of the golang-lru/v2 package.
Based on the analysis of the codebase, I can now provide a final response:
golang-lru/v2 dependency is valid and required
The golang-lru/v2 package is an indirect dependency brought in by the Slinky integration, which is a core part of the project's oracle functionality. The dependency is properly versioned and does not conflict with any other caching implementations in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for golang-lru imports and usage
rg -l "github.com/hashicorp/golang-lru"
# Search for other potential caching libraries
rg -l "cache" --type go
# Check if golang-lru is used directly or indirectly
rg "lru\." --type go -A 2
Length of output: 243
Script:
#!/bin/bash
# Search for golang-lru v2 imports
rg -l "github.com/hashicorp/golang-lru/v2"
# Check cache implementations in the found files
cat warden/app/app.go
cat warden/app/sim_test.go
cat warden/x/act/keeper/actions.go
cat cmd/wardend/cmd/config.go
Length of output: 48222
Script:
#!/bin/bash
# Search for any direct imports or usage of golang-lru/v2
rg -l "github.com/hashicorp/golang-lru/v2"
# Check the dependencies that might be using golang-lru/v2
cat tests/slinky/go.mod
Length of output: 14276
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
warden/app/oracle.go (2)
123-126: Check for potential decompression and performance pitfalls.Using ZLib compression for vote extensions can be prone to large payload decompression overhead. Consider adding safeguards against oversized or maliciously crafted data.
220-223: Add a doc comment for the exported struct.Exported Go structs should include a doc comment describing their purpose. This improves maintainability and clarity for future contributors.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (4)
api/warden/async/v1beta1/ve.pulsar.gois excluded by!api/**api/warden/vemanager/vemanager.pulsar.gois excluded by!api/**warden/app/vemanager/vemanager.pb.gois excluded by!**/*.pb.gowarden/x/async/types/v1beta1/ve.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (22)
CHANGELOG.md(0 hunks)go.mod(1 hunks)prophet/dedup.go(0 hunks)prophet/doc.go(0 hunks)prophet/exec.go(0 hunks)prophet/future.go(0 hunks)prophet/handlers.go(0 hunks)prophet/handlers/echo/echo.go(0 hunks)prophet/prophet.go(0 hunks)prophet/registry.go(0 hunks)proto/warden/async/v1beta1/ve.proto(0 hunks)proto/warden/vemanager/vemanager.proto(0 hunks)warden/app/app.go(0 hunks)warden/app/oracle.go(4 hunks)warden/app/vemanager/vemanager.go(0 hunks)warden/testutil/keeper/async.go(0 hunks)warden/x/async/keeper/abci.go(1 hunks)warden/x/async/keeper/abci_test.go(0 hunks)warden/x/async/keeper/futures.go(0 hunks)warden/x/async/keeper/keeper.go(0 hunks)warden/x/async/module/module.go(0 hunks)warden/x/async/types/v1beta1/future.go(0 hunks)
💤 Files with no reviewable changes (19)
- warden/x/async/types/v1beta1/future.go
- proto/warden/vemanager/vemanager.proto
- prophet/registry.go
- warden/x/async/module/module.go
- warden/x/async/keeper/abci_test.go
- prophet/future.go
- prophet/handlers/echo/echo.go
- warden/x/async/keeper/keeper.go
- prophet/doc.go
- warden/testutil/keeper/async.go
- warden/app/app.go
- proto/warden/async/v1beta1/ve.proto
- prophet/handlers.go
- warden/x/async/keeper/futures.go
- CHANGELOG.md
- prophet/dedup.go
- warden/app/vemanager/vemanager.go
- prophet/exec.go
- prophet/prophet.go
🧰 Additional context used
📓 Path-based instructions (2)
warden/app/oracle.go (1)
Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
warden/x/async/keeper/abci.go (1)
Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
🔇 Additional comments (6)
go.mod (1)
Line range hint 6-6: Verify security status of requests dependency
Let's verify if the pinned version of requests (2.26.0) has any known security vulnerabilities.
warden/x/async/keeper/abci.go (1)
3-3: No issues found with the import.
The import of the "context" package is appropriate. However, confirm that an empty EndBlocker still meets your module’s requirements after reverting the previous functionality.
warden/app/oracle.go (4)
9-10: Ensure these imports are utilized optimally.
Both "storetypes" and "upgradetypes" appear relevant to the new “AppUpgrade” struct. Confirm that you use all functions or types from these packages. Otherwise, consider removing them.
✅ Verification successful
Let me verify the usage of these imports by searching through the codebase.
Both imports are properly utilized in the AppUpgrade struct
Both storetypes and upgradetypes imports are correctly used in the AppUpgrade struct definition at the end of the file:
upgradetypes.UpgradeHandleris used for theHandlerfieldstoretypes.StoreUpgradesis used for theStoreUpgradefield
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for usage of storetypes and upgradetypes in oracle.go
rg -l "storetypes\.|upgradetypes\." warden/app/oracle.go
# Show the content of oracle.go to analyze the usage
cat warden/app/oracle.go
Length of output: 7082
146-149: Confirm consistency of compression algorithms.
Here you use ZStd, while the vote extensions use ZLib. If there’s no functional reason for different compressors, consider standardizing on a single approach.
16-17: Validate necessity of slinkytypes import.
This import seems to support aggregator logic in the code (e.g. CurrencyPair usage). Double-check that it's essential; if not, remove to keep dependencies lean.
✅ Verification successful
Let me verify the necessity of the slinkytypes import by searching for its usage in the codebase.
Let me search for actual usage of the slinkytypes import in the oracle.go file to verify its necessity.
The slinkytypes import is essential - keep it.
The import is actively used in the AggregatorFn method's return type signature where it's part of the generic type parameter map[slinkytypes.CurrencyPair]*big.Int. This is a core part of the oracle's aggregation functionality and cannot be removed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for usage of slinkytypes or CurrencyPair in the codebase
rg -l "slinkytypes\."
rg "CurrencyPair" -A 3 -B 3
Length of output: 97914
Script:
#!/bin/bash
# Search for actual usage of slinkytypes in oracle.go
rg -A 3 -B 3 "slinkytypes\." warden/app/oracle.go
Length of output: 329
213-217: Validate ABCI handlers post-revert.
With the revert of the prophet code, ensure these ABCI handlers for proposals, pre-block, and vote extensions still align with the intended logic.
✅ Verification successful
Let me gather information about the ABCI handlers to verify their implementation and alignment.
Let me search specifically for the Slinky handlers and their implementations.
Let me check the Slinky client implementation and its initialization.
Based on the gathered information, I can now provide a final response:
ABCI handlers are properly integrated with Slinky framework
The code shows that the ABCI handlers are correctly initialized and integrated with the Slinky framework. The handlers are:
- Properly instantiated through the Slinky client (
app.slinkyClient) - Connected to the base handlers and module manager
- Verified through integration tests in the
tests/slinkydirectory - Have all required dependencies imported from the
skip-mev/slinkypackages
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for the handler implementations
ast-grep --pattern 'type $_ struct {
$$$
}
func ($_ *$_) PrepareProposalHandler() $_ {
$$$
}'
# Look for related test files
fd -e go -E "vendor|node_modules" test
# Search for any prophet-related code that might have been missed
rg -i "prophet" -g "*.go" -A 2 -B 2
Length of output: 1817
Script:
#!/bin/bash
# Search for Slinky handler implementations
rg -g "*.go" "slinkyProposalHandler|slinkyPreBlockHandler|slinkyVEHandler" -A 5 -B 5
# Look for the handler struct definitions
ast-grep --pattern 'type $handler struct {
$$$
}'
# Search for any test files related to these handlers
rg -g "*_test.go" "PrepareProposalHandler|ProcessProposalHandler|PreBlocker|ExtendVoteHandler|VerifyVoteExtensionHandler"
Length of output: 1582
Script:
#!/bin/bash
# Search for slinkyClient initialization and structure
rg -g "*.go" "slinkyClient" -A 5 -B 5
# Look for the Slinky package imports
rg -g "*.go" "\"github.com/skip-mev/slinky" -A 2 -B 2
# Check the tests directory for Slinky-related tests
rg -g "*.go" -t go "slinky" ./tests
Length of output: 7997
| @@ -218,6 +217,7 @@ require ( | |||
| github.com/hashicorp/go-safetemp v1.0.0 // indirect | |||
| github.com/hashicorp/go-version v1.7.0 // indirect | |||
| github.com/hashicorp/golang-lru v1.0.2 // indirect | |||
| github.com/hashicorp/golang-lru/v2 v2.0.7 // indirect | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Remove duplicate golang-lru/v2 dependency
This dependency is already handled by the replace directive. Having it listed separately in the require section is redundant and could potentially lead to version conflicts.
- github.com/hashicorp/golang-lru/v2 v2.0.7 // indirectCommittable suggestion skipped: line range outside the PR's diff.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
warden/x/async/keeper/abci.go (1)
3-3: Consider removing or documenting no-op methods.Both BeginBlocker and EndBlocker are currently placeholders that do nothing. If they are not required to satisfy a specific interface contract, consider removing them. If they must remain, add a brief comment clarifying why they are intentionally left as no-ops.
warden/app/oracle.go (3)
123-126: Unify or document compression method choices.Here you use ZLib for vote extension compression, whereas ZStd is used for extended commit compression (see lines 146–149). If there's no specific reason to mix these, consider standardizing on a single compressor for maintainability and consistency.
146-149: Consider consistent compression usage.Same note as above—verify that using ZStd here and ZLib in line 123–126 is intentional. If uniformity reduces complexity, adopting a single compressor may be preferable.
220-223: Add doc comments for exported struct.Consider adding a brief doc comment to “AppUpgrade” to conform with Go conventions for exported types.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (4)
api/warden/async/v1beta1/ve.pulsar.gois excluded by!api/**api/warden/vemanager/vemanager.pulsar.gois excluded by!api/**warden/app/vemanager/vemanager.pb.gois excluded by!**/*.pb.gowarden/x/async/types/v1beta1/ve.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (22)
CHANGELOG.md(0 hunks)go.mod(1 hunks)prophet/dedup.go(0 hunks)prophet/doc.go(0 hunks)prophet/exec.go(0 hunks)prophet/future.go(0 hunks)prophet/handlers.go(0 hunks)prophet/handlers/echo/echo.go(0 hunks)prophet/prophet.go(0 hunks)prophet/registry.go(0 hunks)proto/warden/async/v1beta1/ve.proto(0 hunks)proto/warden/vemanager/vemanager.proto(0 hunks)warden/app/app.go(0 hunks)warden/app/oracle.go(4 hunks)warden/app/vemanager/vemanager.go(0 hunks)warden/testutil/keeper/async.go(0 hunks)warden/x/async/keeper/abci.go(1 hunks)warden/x/async/keeper/abci_test.go(0 hunks)warden/x/async/keeper/futures.go(0 hunks)warden/x/async/keeper/keeper.go(0 hunks)warden/x/async/module/module.go(0 hunks)warden/x/async/types/v1beta1/future.go(0 hunks)
💤 Files with no reviewable changes (19)
- warden/x/async/types/v1beta1/future.go
- prophet/handlers/echo/echo.go
- prophet/doc.go
- warden/x/async/module/module.go
- warden/x/async/keeper/abci_test.go
- warden/testutil/keeper/async.go
- warden/app/app.go
- proto/warden/async/v1beta1/ve.proto
- prophet/handlers.go
- proto/warden/vemanager/vemanager.proto
- warden/x/async/keeper/futures.go
- prophet/exec.go
- prophet/dedup.go
- warden/x/async/keeper/keeper.go
- prophet/registry.go
- prophet/future.go
- CHANGELOG.md
- warden/app/vemanager/vemanager.go
- prophet/prophet.go
🧰 Additional context used
📓 Path-based instructions (2)
warden/app/oracle.go (1)
Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
warden/x/async/keeper/abci.go (1)
Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
🔇 Additional comments (4)
warden/app/oracle.go (3)
9-10: Approved import clean-up and addition.
The newly added imports look valid and align with the file’s updated logic.
16-17: Approved import for slinkytypes.
No issues identified. The import is consistent with the rest of the refactored code.
213-217: Lifecycle upgrades acknowledged.
These setter calls for ABCI lifecycle handlers appear consistent with the new approach. Any references to the removed prophet logic have been cleared correctly.
go.mod (1)
220-220: Verify dependency security state.
The “golang-lru/v2 v2.0.7” module is listed as an indirect dependency. Ensure there are no unresolved security advisories before finalizing.
✅ Verification successful
No security advisories found for golang-lru/v2 v2.0.7
The GitHub Security Advisory Database shows no known vulnerabilities for this dependency at the specified version.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check GitHub advisories for known vulnerabilities in golang-lru/v2 at version 2.0.7
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: GO, package: "github.com/hashicorp/golang-lru/v2") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
Length of output: 367
Reverts #1141
Chain with >1 validators and slinky has errors
Summary by CodeRabbit
New Features
SendWaitTx.Consensus Breaking Changes
SignRequeststructure with a newbroadcastType.Bug Fixes
Documentation
CHANGELOG.mdto reflect new features, changes, and bug fixes.