Closed rootulp closed 1 week ago
The changes in prepare_proposal_test.go
focus on renaming the variable accnts
to accounts
throughout the file. This involves updating all instances of the variable in function calls and array slices related to account information. The primary goal is to improve code readability and maintain consistency in naming conventions.
File | Change Summary |
---|---|
app/test/prepare_proposal_test.go |
Renamed variable accnts to accounts throughout the file for consistency |
(No changes made to control flow or interactions between components, so diagram generation was skipped.)
Objective | Addressed | Explanation |
---|---|---|
Unit test to ensure prepare proposal does not exceed BlockDataSize in ResponsePrepareProposal.BlockData.Txs (#3573) |
❌ | No new unit tests were added to address this specific requirement. |
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?
Is this some form of defensive programming in the instance that we modify the algorithm such that there is a possibility that bytes are added and that therefore this test would catch it?
Is this some form of defensive programming in the instance that we modify the algorithm such that there is a possibility that bytes are added and that therefore this test would catch it?
Unfortunately I don't think this test would actually catch it because it doesn't fuzz inputs into prepare proposal. If we wanted to be defensive then we would have to add the explicit check in prepare proposal (see PR description).
This PR is motivated by the last audit finding. It communicates the "intention" of prepare proposal but doesn't actually enforce any new constraints.
Yeah, I'm a little confused by it's existence. Are you saying it's there just to communicate to people that we don't expect PrepareProposal
to somehow increase the bytes returned?
Yea exactly
Discussed with @cmwaters offline and we decided this informational audit finding should just be acknowledged and the unit test doesn't add much value.
Closes https://github.com/celestiaorg/celestia-app/issues/3573
Note: we could add an explicit conditional at the end of prepare proposal like:
but I'm not sure that actually gets us much. Instead of panic'ing in celestia-core (like it does currently), it'll panic in celestia-app. Since this is a change to prepare proposal which has already been audited, I'm hesitant to add the conditional unless reviewers feel strongly that it is helpful.