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

(Backport) fix(x/authz)!: limit expired authz grant pruning to 200 per block #513

Merged
merged 4 commits into from
Mar 9, 2024

Conversation

mattverse
Copy link
Member

@mattverse mattverse commented Feb 6, 2024

Description

Backport of PR 18737 and PR 19315 from upstream


Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

Summary by CodeRabbit

  • Refactor
    • Improved the efficiency of pruning expired grants by introducing a limit to the number of records processed at once.
  • Tests
    • Added tests to ensure the new pruning behavior works as expected with various limits.

@@ -8,7 +8,7 @@
// BeginBlocker is called at the beginning of every block
func BeginBlocker(ctx sdk.Context, keeper keeper.Keeper) {
// delete all the mature grants
if err := keeper.DequeueAndDeleteExpiredGrants(ctx); err != nil {
if err := keeper.DequeueAndDeleteExpiredGrants(ctx, 200); err != nil {

Check warning

Code scanning / CodeQL

Panic in BeginBock or EndBlock consensus methods Warning

path flow from Begin/EndBlock to a panic call
path flow from Begin/EndBlock to a panic call
path flow from Begin/EndBlock to a panic call
path flow from Begin/EndBlock to a panic call
path flow from Begin/EndBlock to a panic call
@czarcas7ic
Copy link
Member

Because this isn't state compatible, lets target the osmo/v0.47.5 branch. That will behave like our "main" branch

@mattverse
Copy link
Member Author

@czarcas7ic I think 54cc86a this PR also might have been state breaking should we revert it and also have it targeted toward osmo/v0.47.5 branch?

@czarcas7ic czarcas7ic changed the base branch from osmo-v22/v0.47.5 to osmo/v0.47.5 February 8, 2024 19:25
Copy link

coderabbitai bot commented Mar 8, 2024

Warning

Rate Limit Exceeded

@czarcas7ic has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 3 minutes and 11 seconds before requesting another review.

How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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.
Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.
Please see our FAQ for further information.

Commits Files that changed from the base of the PR and between 910b67d and 155e7ad.

Walkthrough

The recent updates involve modifying the DequeueAndDeleteExpiredGrants function in the Keeper structure to accept an additional limit parameter. This adjustment allows for controlling the number of iterations and consequently, the records pruned during each execution to avoid excessive processing time. Accompanying tests ensure the functionality behaves as expected with various limit values. Additionally, the BeginBlocker function now incorporates this change by specifying a limit when calling DequeueAndDeleteExpiredGrants, aiming to enhance performance and reliability in handling expired grants.

Changes

Files Change Summary
.../keeper/keeper.go
.../keeper/keeper_test.go
Added limit int parameter to DequeueAndDeleteExpiredGrants in Keeper; introduced tests for different limit values.
.../module/abci.go Modified BeginBlocker to call DequeueAndDeleteExpiredGrants with a 200 limit.

🐰✨
In the realm of code, where the bits align,
A rabbit hopped in, with a change so fine.
"Let's limit our loops," it said with a grin,
"To keep our system sprightly, and let efficiency win."
So with a tweak and a test, the job was done,
Now the code runs smoother, under the virtual sun.
🌟🐇

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>.
    • Generate unit-tests 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 tests 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 generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit tests.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • The JSON schema for the configuration file is available here.
  • 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/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

Copy link

@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.

Review Status

Actionable comments generated: 1

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 24e7758 and 910b67d.
Files selected for processing (3)
  • x/authz/keeper/keeper.go (2 hunks)
  • x/authz/keeper/keeper_test.go (2 hunks)
  • x/authz/module/abci.go (1 hunks)
Additional comments: 2
x/authz/keeper/keeper.go (1)
  • 374-394: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [377-408]

The implementation of the limit parameter in the DequeueAndDeleteExpiredGrants function is a significant improvement aimed at enhancing performance by controlling the number of expired grants pruned per block. This change effectively addresses potential performance bottlenecks by limiting the loop iterations based on the provided limit. However, it's crucial to ensure that the function correctly handles edge cases, such as when the limit is set to 0 (indicating no pruning should occur) or when it's set to a very high number that could potentially prune more grants than available. It would be beneficial to add tests covering these edge cases to ensure the system behaves as expected under various conditions.

x/authz/keeper/keeper_test.go (1)
  • 392-465: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [373-461]

The modifications to the tests in keeper_test.go, including the addition of the limit parameter to the DequeueAndDeleteExpiredGrants function calls and the introduction of new tests to verify the pruning behavior based on different limit values, are commendable. These changes help ensure that the new functionality works as expected under various conditions. It's crucial to maintain comprehensive test coverage, especially for edge cases and scenarios that might involve concurrent modifications to the grants being pruned. Consider adding more tests to cover such scenarios, ensuring the system's resilience and reliability.

@@ -8,7 +8,7 @@ import (
// BeginBlocker is called at the beginning of every block
func BeginBlocker(ctx sdk.Context, keeper keeper.Keeper) {
// delete all the mature grants
if err := keeper.DequeueAndDeleteExpiredGrants(ctx); err != nil {
if err := keeper.DequeueAndDeleteExpiredGrants(ctx, 200); err != nil {
Copy link

Choose a reason for hiding this comment

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

The addition of a limit parameter to the DequeueAndDeleteExpiredGrants function call within the BeginBlocker function is a critical change aimed at improving performance by controlling the number of expired grants pruned per block. This approach helps in preventing potential performance bottlenecks when dealing with a large number of expired grants. However, the use of panic for error handling in this context raises concerns. In blockchain systems, stability is crucial, and panicking could lead to unintended consequences, including halting the blockchain. It's advisable to consider a more resilient error handling strategy that allows the system to gracefully handle errors without compromising stability.

@czarcas7ic czarcas7ic merged commit b053839 into osmo/v0.47.5 Mar 9, 2024
22 checks passed
@czarcas7ic czarcas7ic deleted the mattverse/bpt-3 branch March 9, 2024 05:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants