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

Re-enable tests in ics02_client and foreign_client #535

Merged
merged 29 commits into from
Jan 25, 2021

Conversation

adizere
Copy link
Member

@adizere adizere commented Jan 19, 2021

Closes: #469

This PR re-enables the tests in the ics02_client and foreign_client modules.

The ibc::handler::Event type was removed. Handlers now produce IBCEvents.


For contributor use:

  • Updated the Unreleased section of CHANGELOG.md with the issue.
  • If applicable: Unit tests written, added test to CI.
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Updated relevant documentation (docs/) and code comments.
  • Re-reviewed Files changed in the Github PR explorer.

@codecov-io
Copy link

codecov-io commented Jan 19, 2021

Codecov Report

Merging #535 (03c2469) into master (b1b37f5) will increase coverage by 31.9%.
The diff coverage is 67.8%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master    #535      +/-   ##
=========================================
+ Coverage    13.6%   45.5%   +31.9%     
=========================================
  Files          69     134      +65     
  Lines        3752    8640    +4888     
  Branches     1374       0    -1374     
=========================================
+ Hits          513    3938    +3425     
- Misses       2618    4702    +2084     
+ Partials      621       0     -621     
Impacted Files Coverage Δ
...application/ics20_fungible_token_transfer/error.rs 0.0% <0.0%> (ø)
...pplication/ics20_fungible_token_transfer/events.rs 0.0% <ø> (ø)
...ion/ics20_fungible_token_transfer/msgs/transfer.rs 0.0% <0.0%> (ø)
modules/src/events.rs 0.0% <0.0%> (ø)
modules/src/ics02_client/error.rs 100.0% <ø> (ø)
modules/src/ics02_client/raw.rs 0.0% <0.0%> (ø)
modules/src/ics03_connection/error.rs 100.0% <ø> (+66.6%) ⬆️
modules/src/ics03_connection/msgs/conn_open_try.rs 86.7% <ø> (ø)
modules/src/ics03_connection/version.rs 97.6% <ø> (ø)
modules/src/ics04_channel/channel.rs 71.2% <ø> (+56.1%) ⬆️
... and 245 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a1c393f...4ffe9bb. Read the comment docs.

@vitorenesduarte vitorenesduarte marked this pull request as ready for review January 22, 2021 14:06
res.client_state.latest_height(),
res.consensus_state,
)?;
Ok(vec![ClientEvent::ClientCreated(client_id)])
Copy link
Contributor

Choose a reason for hiding this comment

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

Events were being created both here and at the handlers. Now they're only created at the handlers.

Copy link
Member Author

Choose a reason for hiding this comment

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

This looks better & cleaner!

Just to note that In future (or in other handlers) we may find it useful to create events both from the process method of the handlers, as well as from the ClientKeeper. Then we would collect both of these vectors of events into a single one in ICS26::dispatch. But that's not for now..

.collect()
const CONSENSUS_HEIGHT_ATTRIBUTE_KEY: &str = "consensus_height";

pub fn try_from_tx(event: &tendermint::abci::Event) -> Option<IBCEvent> {
Copy link
Contributor

Choose a reason for hiding this comment

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

This PR touches the translation from tendermint::abci::Event to IBCEvent (here and in other modules) but didn't have to. This was done while generalizing the translation to not be specific to tendermint::abci::Event. This turned out to not be necessary after removing the ibc::handler::Event. Nevertheless, in the process of generalising this, some improvements were made and we may want to keep them.

@@ -87,7 +88,13 @@ pub(crate) fn process(
connection_end: new_connection_end,
};

output.emit(ConnOpenTry(result.clone()));
// TODO: move connection id decision (`next_connection_id` method) in ClientReader
Copy link
Contributor

Choose a reason for hiding this comment

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

This TODO was moved from modules/src/ics03_connection/handler.rs

@vitorenesduarte vitorenesduarte changed the title Testing & cleanup: follow-up to migration work Re-enable tests in ics02_client and foreign_client Jan 22, 2021
Copy link
Member Author

@adizere adizere left a comment

Choose a reason for hiding this comment

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

Looking good, left a few ideas.

res.client_state.latest_height(),
res.consensus_state,
)?;
Ok(vec![ClientEvent::ClientCreated(client_id)])
Copy link
Member Author

Choose a reason for hiding this comment

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

This looks better & cleaner!

Just to note that In future (or in other handlers) we may find it useful to create events both from the process method of the handlers, as well as from the ClientKeeper. Then we would collect both of these vectors of events into a single one in ICS26::dispatch. But that's not for now..

}

#[derive(Clone, Debug, PartialEq, Eq)]
pub struct Event {
Copy link
Member Author

Choose a reason for hiding this comment

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

If you wish, I suggest once we're done with this we do a follow-up PR to update ADR003 events section, making it clear that handlers are using the strongly-typed events, not these loosely-typed events.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we open an issue for that? It's probably better if someone familiar with that ADR does the change.

Kind::ClientIdentifierConstructor(msg.client_state().client_type(), id_counter).context(e)
})?;

output.log("success: generated new client identifier");
Copy link
Member Author

Choose a reason for hiding this comment

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

Just a heads-up: It may be a prerequisite for doing the MBT work that we use a more principled approach to emit these log lines. So maybe have a centralized place in the modules where we enumerate all the kinds of log lines; these could also be loosely coupled with IBCEvents (since they appear in tandem).

modules/src/ics04_channel/msgs.rs Show resolved Hide resolved
modules/src/ics26_routing/handler.rs Show resolved Hide resolved
relayer/src/foreign_client.rs Show resolved Hide resolved
@vitorenesduarte
Copy link
Contributor

Thanks for the review @adizere. I've addressed your suggestions.

@vitorenesduarte vitorenesduarte merged commit d45fcee into master Jan 25, 2021
@vitorenesduarte vitorenesduarte deleted the adi/469_tests branch February 13, 2021 09:26
hu55a1n1 pushed a commit to hu55a1n1/hermes that referenced this pull request Sep 13, 2022
…ms#535)

* ClientId constructor; re-enabled ClientCreate tests

* Improved ics18; Fixed cfg cargo annotation.

* Prep for fixing ForeignClient tests.

* Enable tests in the foreign_client module

* Reuse Height parsing

* More idiomatic methods in ibc::mock::context::MockContext

* Improve assert in build_create_client_and_send

* Remove ibc::handler::Event

* Fix extract_connection_id

* Check IBCEvent produced in create_client

* Check IBCEvent produced in test_tm_create_client_ok

* update CHANGELOG

* relayer: improve tests in foreign_client

Co-authored-by: Vitor Enes <vitorenesduarte@gmail.com>
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.

Follow-up to migration work
3 participants