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

Refactor RecvPacket handler and Acknowledgement types #364

Merged
merged 17 commits into from
Jan 26, 2023

Conversation

plafer
Copy link
Contributor

@plafer plafer commented Jan 20, 2023

Closes: #361
Closes: #369

Description

This PR contains consensus-breaking changes: serialization of successful acknowledgements of packets in onRecvPacket() changed (in order to become compliant with ibc-go).


PR author checklist:

  • Added changelog entry, using unclog.
  • Added tests.
  • Linked to GitHub issue.
  • Updated code comments and documentation (e.g., docs/).
  • Tagged one reviewer who will be the one responsible for shepherding this PR.

Reviewer checklist:

  • Reviewed Files changed in the GitHub PR explorer.
  • Manually tested (in case integration/unit/mock tests are absent).

@codecov
Copy link

codecov bot commented Jan 20, 2023

Codecov Report

Base: 60.00% // Head: 60.42% // Increases project coverage by +0.42% 🎉

Coverage data is based on head (81e970d) compared to base (06abed0).
Patch coverage: 69.23% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #364      +/-   ##
==========================================
+ Coverage   60.00%   60.42%   +0.42%     
==========================================
  Files         124      124              
  Lines       15650    15665      +15     
==========================================
+ Hits         9391     9466      +75     
+ Misses       6259     6199      -60     
Impacted Files Coverage Δ
crates/ibc/src/applications/transfer/context.rs 44.11% <0.00%> (-0.27%) ⬇️
crates/ibc/src/applications/transfer/events.rs 8.33% <0.00%> (ø)
...c/src/applications/transfer/relay/on_ack_packet.rs 0.00% <0.00%> (ø)
.../src/applications/transfer/relay/on_recv_packet.rs 0.00% <0.00%> (ø)
...s/ibc/src/applications/transfer/acknowledgement.rs 84.09% <83.63%> (+10.62%) ⬆️
crates/ibc/src/core/ics04_channel/handler.rs 97.07% <100.00%> (+10.43%) ⬆️
crates/ibc/src/core/ics26_routing/context.rs 43.84% <100.00%> (-2.26%) ⬇️
crates/ibc/src/mock/context.rs 66.55% <100.00%> (+1.23%) ⬆️
crates/ibc/src/test_utils.rs 62.13% <100.00%> (+1.14%) ⬆️
... and 4 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@plafer plafer requested a review from Farhad-Shabani January 23, 2023 22:25
@plafer plafer marked this pull request as ready for review January 23, 2023 22:25
Copy link
Member

@Farhad-Shabani Farhad-Shabani left a comment

Choose a reason for hiding this comment

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

Your accuracy and attention to detail is admirable and instructive to me. 👌
I left some suggestions. It's likely I'll revisit this as I gain more knowledge about different acknowledgements

}

impl AsRef<[u8]> for Acknowledgement {
fn as_ref(&self) -> &[u8] {
match self {
Acknowledgement::Success(_) => ACK_SUCCESS_B64.as_bytes(),
Acknowledgement::Success(_) => r#"{"result":"AQ=="}"#.as_bytes(),
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note that I'm still investigating whether this is correct

Copy link
Member

Choose a reason for hiding this comment

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

If it is indeed correct, can we use the serde_json implementation instead of the hardcoded version? This would help ensure the two don't go out of sync and is a bit cleaner imho than hardcoding some JSON in there, at a small cost of efficiency though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What I still need to investigate is whether spaces matter in the resulting json. In the case where they do, I would prefer the hardcoded version since I don't know if serde_json::to_string() adds spaces or not, and I don't want to have to go check every time I forget (or be worried every time we update serde-json). WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note that I confirmed that this is the correct output.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What I still need to investigate is whether spaces matter in the resulting json. In the case where they do, I would prefer the hardcoded version since I don't know if serde_json::to_string() adds spaces or not, and I don't want to have to go check every time I forget (or be worried every time we update serde-json). WDYT?

Spaces don't matter; see issue comment. However, what I don't like about serde_json::to_string() is that it returns a Result which we would have to unwrap(). Ideally, I would prefer if we didn't have any unwrap()s in the code, as they make audits of the code more difficult (that's an extra thing to check), and every time I update serde-json I'd ideally need to verify that the Error conditions didn't change. What's your take on this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will merge for now; we can always open an issue to improve this

@plafer
Copy link
Contributor Author

plafer commented Jan 25, 2023

Note that I fixed the Error acknowledgement too in this PR, and added a test. I hardcoded the json output for now; might use serde-json instead depending on outcome of this thread.

Otherwise, everything is in there, and is ready for a final review.

Copy link
Member

@Farhad-Shabani Farhad-Shabani left a comment

Choose a reason for hiding this comment

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

A few nits and we're done. Thank you so much 🙏

Copy link
Member

@Farhad-Shabani Farhad-Shabani left a comment

Choose a reason for hiding this comment

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

🌷

@plafer plafer merged commit 8ed5c7e into main Jan 26, 2023
@plafer plafer deleted the plafer/361-rm-async-acks branch January 26, 2023 16:39
Farhad-Shabani pushed a commit that referenced this pull request Sep 9, 2024
* refactor

* change `AsRef` impl for ICS-20 Ack

* test success ack

* revert `Acknowledgement::AsRef` for `Error`

* document standard divergence

* Rename GenericAcknowledgement

* refactor transfer on_recv_packet()

* Remove `Default` for acks

* Rename TokenTransferAcknowledgement

* changelog

* Fix error ack for ics20

* ics20: test error ack

* use is_successful()

* refactor test

* remove AsRef
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICS-20: Acknowledgement::AsRef<u8> is incorrect Remove support for asynchronous acks for RecvPacket
3 participants