feat: limit the number of messages in prepare proposal #3942
Conversation
rach-id
requested review from
cmwaters and
ninabarbakadze
and removed request for
a team
📝 Walkthrough📝 WalkthroughWalkthroughThe changes in this pull request enhance the testing framework and transaction filtering logic within the application. New test functions are introduced to validate transaction limits for different transaction types, while existing functions are modified to enforce caps on specific transactions. Additionally, new constants are added to define these limits, improving the overall configuration of transaction handling. Changes
Possibly related PRs
Suggested labels
Suggested reviewers
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: 5
🧹 Outside diff range and nitpick comments (1)
pkg/appconsts/v3/app_consts.go (1)
9-13: Consider documenting the overall impact of transaction caps and their future adjustments.The introduction of MsgSendTransactionCap and PFBTransactionCap is a significant change that could impact the system's behavior and performance. To ensure clarity and maintainability, please consider:
- Documenting the combined effect of these caps on the overall block size and transaction throughput.
- Explaining the rationale behind having separate caps for different transaction types.
- Outlining any plans for future adjustments to these caps based on network performance or other factors.
- Adding a comment referencing the benchmarks or analysis used to determine these values, as mentioned in the previous review.
This documentation will be crucial for understanding the system's constraints and for future optimizations.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (4)
- app/test/prepare_proposal_test.go (2 hunks)
- app/validate_txs.go (5 hunks)
- pkg/appconsts/v3/app_consts.go (1 hunks)
- test/util/test_app.go (4 hunks)
🧰 Additional context used
🔇 Additional comments (8)
pkg/appconsts/v3/app_consts.go (2)
12-13: Please provide more context for the PFBTransactionCap value and clarify the term "PFB".The introduction of this constant is beneficial for limiting PFB messages per block. However, could you please address the following points:
- What does "PFB" stand for in this context?
- How was the value of 2700 determined?
- What are the implications of this limit on the system's performance and behavior?
- Is this limit subject to change based on network conditions or future optimizations?
Adding comments in the code to explain these points and the meaning of "PFB" would greatly improve maintainability and understanding for future developers.
To ensure this constant is used correctly throughout the codebase, let's run a quick check:
#!/bin/bash # Search for usages of PFBTransactionCap rg --type go "PFBTransactionCap"
9-10: Please provide more context for the MsgSendTransactionCap value.The introduction of this constant is a good step towards limiting the number of transactions per block. However, could you please provide more information on:
- How was the value of 3200 determined?
- What are the implications of this limit on the system's performance and behavior?
- Is this limit subject to change based on network conditions or future optimizations?
Adding comments in the code to explain these points would greatly improve maintainability and understanding for future developers.
To ensure this constant is used correctly throughout the codebase, let's run a quick check:
app/test/prepare_proposal_test.go (1)
231-231:⚠️ Potential issueVerify the block's
MaxBytessettingLine 231 sets
consensusParams.Block.MaxBytes = 128, which seems unusually low given that the test involves a large number of transactions. This small block size may prevent any transactions from being included in the block during testing, potentially causing the test to not function as intended. Please verify if this value is intentional or if it should be increased to accommodate the test transactions.test/util/test_app.go (5)
67-69: Code refactored for better modularityThe
initialiseTestAppfunction is now used to initialize the test app, promoting code reuse and improving modularity.
71-75: Added function for setting up test app with custom max square sizeThe new
SetupTestAppWithGenesisValSetAndMaxSquareSizefunction allows specifying a custommaxSquareSize, enhancing the flexibility of the test setup.
Line range hint
77-85: NewinitialiseTestAppfunction improves code organizationThe
initialiseTestAppfunction encapsulates the app initialization logic, improving code readability and maintainability.
190-192: Updated function to useInitialiseTestAppWithGenesisThe
NewTestAppWithGenesisSetfunction now usesInitialiseTestAppWithGenesisto initialize the app with the genesis state, ensuring consistency across test setups.
Line range hint
209-240: NewInitialiseTestAppWithGenesisfunction centralizes initialization logicThe
InitialiseTestAppWithGenesisfunction centralizes the app initialization with a given genesis state, enhancing code maintainability and reducing duplication.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
app/validate_txs.go (2)
4-5: Consider using a more descriptive alias instead oftypes2The alias
types2for the imported packagegithub.com/celestiaorg/celestia-app/v3/x/blob/typesis not very descriptive and could lead to confusion. Consider renaming it toblobtypesorblobTypesto enhance readability and clarity.
131-136: Rename variabletypesto avoid confusion with imported packagesUsing
typesas a variable name may cause confusion due to the imported packages namedtypes. Consider renaming the variable tomessageTypesormsgTypeListfor better clarity and to prevent potential conflicts.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
pkg/appconsts/v3/app_consts.go (1)
9-13: Consider adding documentation for the chosen values.While the constants and their purposes are clear, it would be beneficial to add documentation explaining the rationale behind the chosen values (200 for SDK messages and 600 for PFB messages). This will help future maintainers understand the reasoning and implications of these limits.
app/test/prepare_proposal_test.go (1)
250-250: Define magic number2000as a constantConsider defining the value
2000used for the size ofrandomBytesas a constant with a meaningful name to improve code readability.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
- app/test/prepare_proposal_test.go (2 hunks)
- app/validate_txs.go (4 hunks)
- pkg/appconsts/v3/app_consts.go (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- app/validate_txs.go
🧰 Additional context used
🔇 Additional comments (4)
pkg/appconsts/v3/app_consts.go (2)
9-13: LGTM! New constants added for transaction limits.The addition of
SdkMsgTransactionCapandPFBTransactionCapconstants aligns with the PR objective of limiting the number of transactions in the prepare proposal phase. The comments for both constants are clear and descriptive.
9-13: Verify the usage of new constants in the codebase.To ensure these new constants are properly integrated, we should verify their usage throughout the codebase.
Run the following script to check for usage of the new constants:
✅ Verification successful
Usage of new constants verified successfully. No issues found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for usage of new constants in the codebase # Test: Search for SdkMsgTransactionCap usage echo "Searching for SdkMsgTransactionCap usage:" rg --type go "SdkMsgTransactionCap" echo "\nSearching for PFBTransactionCap usage:" rg --type go "PFBTransactionCap"Length of output: 1802
app/test/prepare_proposal_test.go (2)
231-231: Verify the appropriateness ofBlock.MaxBytesvalueSetting
consensusParams.Block.MaxBytes = 128may be too low to accommodate the transactions being generated. Please verify if this value is intentional and sufficient for the test scenarios.
217-335: Test function adds valuable coverageThe new
TestPrepareProposalCappingNumberOfTransactionsfunction effectively tests the capping logic for transactions. The test cases cover various scenarios, ensuring the caps are correctly enforced for both PFB and MsgSend transactions.
…osal # Conflicts: # app/test/prepare_proposal_test.go # app/validate_txs.go # pkg/appconsts/v3/app_consts.go
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
- app/test/prepare_proposal_test.go (2 hunks)
- app/validate_txs.go (6 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- app/validate_txs.go
🧰 Additional context used
🔇 Additional comments (4)
app/test/prepare_proposal_test.go (4)
4-15: New imports look goodThe added imports are necessary for the new test function and there are no unused imports.
297-310: PFB transaction generation looks goodThe PFB transaction generation logic is well-implemented:
- It creates transactions exceeding the cap, which is necessary for testing the capping behavior.
- Random bytes are used for blob content, which is appropriate for this test.
- Using a new account for each transaction avoids sequence number complications.
This approach ensures a robust test of the transaction capping mechanism.
312-324: MsgSend transaction generation is well-implementedThe MsgSend transaction generation logic is solid:
- It creates transactions exceeding the cap, which is necessary for testing the capping behavior.
- Random addresses are used as recipients, adding variability to the test.
- Using a new account for each transaction avoids sequence number complications, consistent with the PFB generation approach.
This implementation provides a good basis for testing the transaction capping mechanism.
270-384: Excellent addition of comprehensive test casesThe new
TestPrepareProposalCappingNumberOfMessagesfunction significantly enhances the test coverage for transaction capping behavior. It includes a variety of scenarios and thoroughly tests the implementation. The setup is comprehensive, and the test cases are well-structured.While there are some minor suggestions for improvement, the overall quality of this addition is high. Great work on expanding the test suite!
celestia-bot
requested review from
a team and
evan-forbes
and removed request for
a team
…prepare-proposal' into limit-number-of-transactions-in-prepare-proposal
|
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
- app/test/prepare_proposal_test.go (2 hunks)
🧰 Additional context used
🪛 GitHub Check: lint / golangci-lint
app/test/prepare_proposal_test.go
[failure] 323-323:
ineffectual assignment to err (ineffassign)
🔇 Additional comments (2)
app/test/prepare_proposal_test.go (2)
4-17: LGTM: New imports are appropriate for the added functionality.The new imports are necessary and relevant for the new test function
TestPrepareProposalCappingNumberOfMessages. They provide access to required types and functions from the Celestia and Cosmos SDKs, as well as the crypto/rand package for generating random data.
273-298: 🛠️ Refactor suggestionConsider parameterizing the number of accounts for faster test runs.
The test creates 8000 accounts, which might lead to long test execution times. Consider parameterizing this value and using a smaller number for quicker test runs, while still allowing for thorough testing with a larger number when needed.
-numberOfAccounts := 8000 +numberOfAccounts := 1000 // Adjust this value as needed for different test scenariosThis change would allow for faster test runs during development while still enabling thorough testing with a larger number of accounts when necessary.
Likely invalid or redundant comment.
There was a problem hiding this comment.
I'm good with merging this now and handling some testApp tech debt later this week
if we do, let's just create issue for
- being able to query info and submit txs using the application alone and no rpc
- use the standard genesis code when building out testapp state
evan-forbes
deleted the
limit-number-of-transactions-in-prepare-proposal
branch
This PR limits the number of transactions in prepare proposal.