-
Notifications
You must be signed in to change notification settings - Fork 331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: disable x/blobstream in v2 #3310
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
Could it be from this: Lines 274 to 277 in 58fc315
|
When does this panic happen? Is it in the genesis block? |
IIRC it was on very early on in |
Yep it was from the blobstream hooks. I'll investigate how to make those hooks versioned because IIUC, we want the staking keeper to have the blobstream hooks in app v1 and not have the blobstream hooks in app v2. |
Warning Rate Limit Exceeded@rootulp has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 48 minutes and 41 seconds before requesting another review. How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. WalkthroughThe changes primarily focus on disabling the Changes
Possibly related issues
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 as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
A bunch of small refactors I made while working on #3310
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for handling this 🙏
Left a few questions to understand more
Co-authored-by: CHAMI Rachid <[email protected]>
A bunch of small refactors I made while working on celestiaorg#3310
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice, does this fully close #3305, specifically point 5 where we migrate state?
Great question! I assumed since the blobstream store key isn't registered in v2, there would be no place to store blobstream state in the multistore but I'll double check that 👀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing all the manual checks.
Perhaps we can modify the upgrade_test.go
in app
to check that blobstream works in v1 and doesn't work in v2. Just a suggestion. Can be done as a follow up
I verified that the blobstream KV store doesn't exist in app version 2. I added this to EndBlocker: store := app.CommitMultiStore().GetKVStore(app.keys[blobstreamtypes.StoreKey])
size := 0
iterator := store.Iterator(nil, nil)
defer iterator.Close()
for ; iterator.Valid(); iterator.Next() {
fmt.Printf("key %v, value %v\n", iterator.Key(), iterator.Value())
size += len(iterator.Key())
size += len(iterator.Value())
}
fmt.Printf("blobstream store size %v\n", size) and when I run a node, I can see that the blobstream store does exist prior to upgrading app versions:
and it does not exist after upgrading app version
|
A bunch of small refactors I made while working on celestiaorg#3310
A bunch of small refactors I made while working on celestiaorg/celestia-app#3310
Closes #3305
Testing
Manually verified on a local devnet that a user can register an EVM address if the chain is on app version 1.
Manually verify on a local devnet that a user can't register an EVM address if the chain is on app version 2.
Manually verified that tx and query CLI commands don't work.
Manually verified that gRPC queries don't work