-
Notifications
You must be signed in to change notification settings - Fork 253
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
feat: emit event for refund in ft_resolve_transfer()
#752
Conversation
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.
Yeah, this makes sense to me. Missed this in #723.
FYI you need to regenerate the examples' wasm files by running ./examples/build_all_docker.sh
in the project directory, otherwise the CI won't pass.
@itegulov thanks. updated. |
I believe the rationale for leaving out in nft (and then what propagated to this) was that since these were optional (iirc) they should not be included in the standard. @telezhnaya @frol I don't have the context to know if this should change, could you weigh in when you get the chance? If we change this, the NFT events should probably as well for consistency |
Explicit minting and burning are indeed optional, but
I have just checked NFT events, and we are already emitting a transfer event when returning an NFT to its previous owner: https://github.com/near/near-sdk-rs/blob/master/near-contract-standards/src/non_fungible_token/core/core_impl.rs#L526. And since NFT standard does not require storage deposits from users, it never has to burn NFTs by itself, so the flow there is a bit different. |
If we send the token back, we should emit the event about it, otherwise, the data will be inconsistent. I agree with the proposed solution. I was also thinking about emitting the event only after we have the result of |
Why is there this inconsistency with nft vs ft standard for the burn event? The same pattern happens with the burn in NFT
|
@austinabell Olga just wanted to confirm that without this fix there will, indeed, be inconsistency, and this fix is correct. |
Reading over the logic again seems like my intuitions were incorrect. Seems the path I linked was handling the case where the token was burned already, so no need to emit the event here. I believe no other change is needed. |
In the standard
fungible_token
implementation, we have emittedFtTransfer
inft_transfer()
, but no events was emitted for refund inft_resolve_transfer()
, which may introduce inconsistency if aggregating the data via FT events such as total deposits and withdrawals.To fix this issue, we can either reuse the current
FtTransfer
,FtBurn
events or create a newFtRefund
event if needed. In this PR, we reuse the existing events.