Skip to content
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

fix: supply offsets for osmo token #8751

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

PaddyMc
Copy link
Contributor

@PaddyMc PaddyMc commented Oct 2, 2024

What is the purpose of the change

Fix the supply offset issues

cosmos-sdk PR => osmosis-labs/cosmos-sdk#629

How to test

before and after in-place-testnet
osmosisd q bank total-supply-of uosmo --output json | jq

beware of dragons:

  • in-place-testnet adds tokens to the total supply so it's best to omit all the added tokens from the in-place-testnet code before testing this PR

Copy link
Contributor

coderabbitai bot commented Oct 2, 2024

Walkthrough

The changes in this pull request include modifications to the constants.go and upgrades.go files within the v27 package, as well as the introduction of a new test suite in upgrades_test.go. A new constant OsmoToken is added, and the existing UpgradeName constant is organized into a block. The CreateUpgradeHandler function is enhanced to manage supply offsets for the OsmoToken. Additionally, a comprehensive testing framework for the upgrade logic is established, ensuring the correct functioning of the upgrade process and related calculations.

Changes

File Change Summary
app/upgrades/v27/constants.go - Added constant OsmoToken with value "uosmo"
- Consolidated UpgradeName into a constant block.
app/upgrades/v27/upgrades.go - Modified CreateUpgradeHandler to handle supply offsets for OsmoToken, including methods for retrieving, adding, and removing supply offsets.
app/upgrades/v27/upgrades_test.go - Introduced UpgradeTestSuite for testing upgrade functionality
- Added methods for setting up and executing supply offset tests.

Possibly related PRs

  • auto: code-gen upgrade handler v27 #8724: This PR introduces a new upgrade handler for version 27, which is directly related to the changes made in the main PR regarding the constants.go and upgrades.go files in the v27 package.

Suggested labels

C:e2e, V:state/compatible/no_backport, A:no-changelog

Suggested reviewers

  • nicolaslara
  • czarcas7ic

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 4c4dca1 and e393ede.

📒 Files selected for processing (1)
  • CHANGELOG.md (1 hunks)
🧰 Additional context used
🔇 Additional comments (9)
CHANGELOG.md (9)

49-49: LGTM: Supply offsets for osmo token fix

This fix addresses an important issue with supply offsets for the osmo token. It's good to see this being resolved.


51-51: Improvement: Additional queries in x/gauges

Adding more queries to the gauges module enhances its functionality and provides more data access points for users and developers.


52-52: Bug fix: Multiple temp directories on command executions

Fixing issues with temporary directories during command executions is important for maintaining a clean and efficient system.


Line range hint 53-53: Bug fix: In-place testnet logs

Improving the logging for in-place testnets will help with debugging and monitoring.


Line range hint 54-54: Bug fix: Unsupported sign-mode issue

Resolving issues with unsupported sign modes is crucial for maintaining compatibility and preventing transaction errors.


Line range hint 55-55: Chore: SDK and CometBFT version bump

Keeping dependencies up-to-date is important for security and performance. Please ensure thorough testing has been done with these new versions.


Line range hint 61-67: New Features and API Changes

These changes introduce new helper functions, mutative operations, and query improvements. While these are generally positive changes, it's important to ensure they are well-documented and that any breaking changes are clearly communicated to users.

#!/bin/bash
# Check for documentation updates related to these new features
rg --type md "sdk.Coins Mul" ./docs
rg --type md "QuoTruncateMut" ./docs
rg --type md "BigDec truncations" ./docs
rg --type md "num initialized ticks query" ./docs

Line range hint 69-70: Performance Improvement: Speedup fractional exponentiation

Performance improvements are always welcome. It would be good to see some benchmarks to quantify the improvement.

#!/bin/bash
# Look for any benchmark tests related to fractional exponentiation
rg --type go "func Benchmark.*Exponentiation" -A 20

Line range hint 57-59: State Machine Breaking Change: Iterate delegations continue instead of erroring

This change modifies the behavior of delegation iteration to continue instead of throwing an error. While this improves robustness, it's important to ensure that this change doesn't mask any underlying issues that should be addressed.


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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@github-actions github-actions bot added the C:app-wiring Changes to the app folder label Oct 2, 2024
@PaddyMc PaddyMc added the V:state/breaking State machine breaking PR label Oct 2, 2024
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (6)
app/upgrades/v27/constants.go (1)

10-13: LGTM! Consider adding a comment for OsmoToken.

The introduction of a constant block improves code organization. The UpgradeName constant remains unchanged, and the new OsmoToken constant is a welcome addition.

Consider adding a brief comment explaining the purpose of the OsmoToken constant, similar to the existing comment for UpgradeName. For example:

const (
    // UpgradeName defines the on-chain upgrade name for the Osmosis v27 upgrade.
    UpgradeName = "v27"
    // OsmoToken defines the denomination for the OSMO token.
    OsmoToken   = "uosmo"
)
app/upgrades/v27/upgrades_test.go (4)

23-25: LGTM: Constant definition is appropriate.

The v27UpgradeHeight constant is well-defined for testing purposes.

Consider adding a brief comment explaining the purpose of this constant, e.g.:

// v27UpgradeHeight represents the block height at which the v27 upgrade is simulated in tests
const v27UpgradeHeight = int64(10)

36-50: LGTM: TestUpgrade method covers the main upgrade scenario.

The method effectively sets up the test environment, executes the upgrade, and checks for potential issues.

Consider adding more specific assertions after the upgrade to verify the expected state changes. For example:

// Add after line 47
s.Require().Equal(v27UpgradeHeight, s.Ctx.BlockHeight(), "Block height should be equal to upgrade height after upgrade")

52-61: LGTM: dummyUpgrade function correctly simulates an upgrade.

The function effectively sets up the upgrade scenario for testing purposes.

Consider adding a comment explaining the purpose of this function, and improve error handling:

// dummyUpgrade simulates an upgrade by scheduling a plan and updating the context
func dummyUpgrade(s *UpgradeTestSuite) {
    // ... existing code ...
    plan, err := s.App.UpgradeKeeper.GetUpgradePlan(s.Ctx)
    s.Require().NoError(err)
    s.Require().Equal(v27.Upgrade.UpgradeName, plan.Name, "Upgrade plan name should match")
}

63-77: LGTM: Supply offset test methods are well-implemented.

The PrepareSupplyOffsetTest and ExecuteSupplyOffsetTest methods effectively set up and verify the supply offset functionality.

Consider adding more test cases to cover edge scenarios:

  1. Test with zero offsets
  2. Test with large (near max int64) offsets
  3. Test with negative total supply

Example:

func (s *UpgradeTestSuite) TestSupplyOffsetEdgeCases() {
    // Test with zero offsets
    s.App.BankKeeper.AddSupplyOffset(s.Ctx, v27.OsmoToken, osmomath.ZeroInt())
    s.App.BankKeeper.AddSupplyOffsetOld(s.Ctx, v27.OsmoToken, osmomath.ZeroInt())
    s.ExecuteSupplyOffsetTest()

    // Test with large offsets
    largeOffset := osmomath.NewIntFromUint64(^uint64(0) >> 1) // Max int64
    s.App.BankKeeper.AddSupplyOffset(s.Ctx, v27.OsmoToken, largeOffset)
    s.ExecuteSupplyOffsetTest()

    // Test with negative total supply
    s.App.BankKeeper.AddSupplyOffset(s.Ctx, v27.OsmoToken, osmomath.NewInt(-1000000))
    s.ExecuteSupplyOffsetTest()
}
app/upgrades/v27/upgrades.go (1)

26-26: Nitpick: Use keepers.BankKeeper directly instead of aliasing to bk.

Since bk is only used in a few places within this function, you might consider using keepers.BankKeeper directly to improve readability and reduce unnecessary variables.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 002d10b and 4c4dca1.

⛔ Files ignored due to path filters (3)
  • go.mod is excluded by !**/*.mod
  • go.sum is excluded by !**/*.sum, !**/*.sum
  • go.work is excluded by !**/*.work, !**/*.work
📒 Files selected for processing (3)
  • app/upgrades/v27/constants.go (1 hunks)
  • app/upgrades/v27/upgrades.go (1 hunks)
  • app/upgrades/v27/upgrades_test.go (1 hunks)
🔇 Additional comments (4)
app/upgrades/v27/constants.go (1)

12-12: Verify the usage of OsmoToken constant.

The introduction of the OsmoToken constant aligns with the PR objective of fixing supply offsets for the osmo token. However, it's not used within this file.

Please ensure that this constant is utilized appropriately in other parts of the codebase related to the supply offset fix. Run the following script to verify its usage:

If the constant is not used, consider removing it or adding a TODO comment explaining its future use.

✅ Verification successful

Usage of OsmoToken is verified and appropriate.

The OsmoToken constant is properly utilized across relevant files in the codebase, aligning with the PR objectives for fixing supply offsets. The occurrences of the string "uosmo" in test and configuration files are appropriate and do not require replacement.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of OsmoToken constant in the codebase.

# Test: Search for OsmoToken usage. Expect: Occurrences in files related to supply offset calculations or token operations.
rg --type go -A 5 'OsmoToken'

# Test: Search for hardcoded "uosmo" strings that could be replaced with OsmoToken. Expect: No occurrences or justified occurrences.
rg --type go -A 5 '"uosmo"'

Length of output: 21612

app/upgrades/v27/upgrades_test.go (3)

1-21: LGTM: Package declaration and imports are appropriate.

The package name and imports are well-structured and relevant for the test suite's requirements.


27-34: LGTM: Test suite structure is well-defined.

The UpgradeTestSuite struct and TestUpgradeTestSuite function are correctly implemented, following Go testing conventions.


1-77: Overall, the test suite is well-implemented and covers key functionality.

The app/upgrades/v27/upgrades_test.go file provides a comprehensive test suite for the v27 upgrade, including the main upgrade scenario and supply offset functionality. The code is well-structured and follows Go testing conventions.

To further enhance the test suite:

  1. Add more detailed comments explaining the purpose of each test function.
  2. Implement additional test cases to cover edge scenarios, especially for supply offset calculations.
  3. Consider adding benchmarks for performance-critical operations, if any.

To ensure comprehensive test coverage, run the following command:

This will help identify any areas that may need additional test cases.

bk := keepers.BankKeeper

// Get the old offset from the old key: []byte{0x88}
offsetOld := bk.GetSupplyOffsetOld(ctx, OsmoToken)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Issue: Undefined variable OsmoToken.

The variable OsmoToken is used but not defined within this file. Please ensure that OsmoToken is properly defined or imported to prevent compilation errors.

Copy link
Member

@czarcas7ic czarcas7ic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK, will of course require in place testnet confirmation once full tag in place. Thanks :)


s.Require().Equal("500uosmo", coin.String())
s.Require().Equal("500", offset.String())
s.Require().Equal("0", oldOffset.String())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this become 0?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the old value is removed from the store! I think we could delete the old state in a later migration to be safe? wdyt?

Copy link
Contributor

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. Thank you!

@github-actions github-actions bot added the Stale label Oct 11, 2024
@github-actions github-actions bot closed this Oct 14, 2024
@PaddyMc PaddyMc removed the Stale label Oct 15, 2024
@PaddyMc PaddyMc reopened this Oct 15, 2024
@czarcas7ic
Copy link
Member

This should be good to merge right? @PaddyMc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:app-wiring Changes to the app folder V:state/breaking State machine breaking PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants