-
Notifications
You must be signed in to change notification settings - Fork 11
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
refactor(core-token-vesting-v2)!: remove recipient #139
Merged
matthiasmatt
merged 3 commits into
main
from
refactor/core-token-vesting-v2/remove-recipient
Mar 11, 2024
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
The test
test_withdraw
correctly reflects the changes made to theExecuteMsg::Withdraw
message by removing therecipient
parameter. However, it's important to ensure that the test cases cover scenarios where the sender is implicitly the recipient of the withdrawal. This is a key part of the PR's objectives, and the tests should explicitly verify that the funds are indeed sent to theinfo.sender
address.Additionally, the test includes a scenario where an unauthorized sender attempts to withdraw funds, which is good for verifying access control. However, it would be beneficial to add a test case that verifies the correct behavior when the sender attempts to withdraw an amount greater than their unallocated balance, ensuring that the contract logic correctly handles such cases.
Consider adding explicit assertions to verify that the withdrawn funds are sent to the
info.sender
address, as this is a critical aspect of the PR's objectives. Also, ensure that edge cases, such as attempting to withdraw more than the available unallocated balance, are adequately tested.The
claim_native
test function has been updated to reflect the removal of therecipient
parameter from theExecuteMsg::Claim
message. This test function is crucial for verifying that the claim functionality works as expected, particularly that the sender (who is also the claimant in this context) receives the claimed funds.While the test does cover scenarios where the claim is made at different times to verify the amount claimable based on the vesting schedule, it would be beneficial to explicitly assert that the funds are sent to the
info.sender
address. Given the PR's objectives, ensuring that the claim functionality defaults the recipient to the sender is essential.Enhance the
claim_native
test by adding explicit assertions to confirm that the claimed funds are sent to theinfo.sender
address. This will ensure that the test suite fully covers the changes made to the claim functionality as per the PR's objectives.