-
Notifications
You must be signed in to change notification settings - Fork 329
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
Relay on all paths defined in the configuration #742
Conversation
/// Registry for keeping track of [`ChainHandle`]s indexed by a `ChainId`. | ||
/// | ||
/// The purpose of this type is to avoid spawning multiple runtimes for a single `ChainId`. | ||
pub struct Registry<'a> { | ||
config: &'a Config, | ||
handles: HashMap<ChainId, Box<dyn ChainHandle>>, | ||
} | ||
|
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.
nice!
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.
Looks good. Should we update the changelog?
Also, it wasn't clear to me what is the expected behavior. Upon starting with no options, assuming a default configuration (with dev-env) is the expected behavior to just start the supervisor for both chains and then stop?
$ hermes start-multi
Finished dev [unoptimized + debuginfo] target(s) in 0.17s
Running `target/debug/hermes start-multi`
{"timestamp":"Mar 16 10:27:00.559","level":"INFO","fields":{"message":"spawning supervisor for chains ibc-0 and ibc-1"},"target":"ibc_relayer_cli::commands::start_multi"}
{"timestamp":"Mar 16 10:27:00.772","level":"INFO","fields":{"message":"running listener","chain.id":"ibc-0"},"target":"ibc_relayer::event::monitor"}
{"status":"success","result":"ok"}
{"timestamp":"Mar 16 10:27:00.875","level":"INFO","fields":{"message":"running listener","chain.id":"ibc-1"},"target":"ibc_relayer::event::monitor"}
That's an oversight on my part, I forgot to commit the code which waits for the threads to finish. There are also other issues with this PR which we discussed with @ancazamfir, so I am going to put it back in draft until I address them (see TODO in PR description). |
…i is ran without options
74c7ab1
to
a36829d
Compare
This comment has been minimized.
This comment has been minimized.
Done. |
relayer/src/supervisor.rs
Outdated
|
||
let src_channel = src_chain.query_channel(src_port_id, src_channel_id, Height::zero())?; | ||
|
||
// TODO: Check channel state? |
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.
Shall we fix the TODO or is this for 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.
It's actually more of a question than a TODO, was hoping you or @ancazamfir could advise me as to what to do here.
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.
If the channel doesn't exist, this query returns an Uninitialized
channel with zero connection hops. So we will see an error when we try to get the connection further down.
Using the following config h/t @romac
|
Not a problem, but got me confused (thinking that an error occurred), but upon running:
There is in the output some error-level messages:
Again, this is not exactly an error: there are no peers configured for the chain (and therefore they cannot be removed). But others may also find it confusing. |
Co-authored-by: Adi Seredinschi <adi@informal.systems>
Yeah that's pretty bad UX, sorry about that. This should be a warning at most or even a different message |
Tracked in #782 |
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.
Looks good! Thanks Romain!
* Make supervisor::collect_events public * Fix rustdoc warning * Spawn a supervisor per connection defined in the config if start-multi is ran without options * Make sure we don't spawn a runtime for the same chain twice * Use a registry to avoid spawning a chain runtime multiple times * Wait for all supervisor threads to finish * Update scripts to spawn three chains * Disable JSON output for start-multi command * Show output and errors of hermes commands in init-clients script * Cleanup * Only send relevant events to the workers * Fix typo * Update scripts to allow spawning either 2 or 3 chains * Send NewBlock events after all other events * Update changelog * Formatting * Remove commented out code Co-authored-by: Adi Seredinschi <adi@informal.systems> * Fix WriteAck object and discard bogus events * Fix for master merge * Check channel and connection state when computing counterparty chain Co-authored-by: Adi Seredinschi <adi@informal.systems>
Closes: #748
Description
If the start-multi command is ran without options, spawn a supervisor per connection defined in the config.
This PR is not ready yet because in a 3 chains setup, some events attached to an object that is not relevant to a worker are forwarded to it anyways.To fix this, we must perform some queries to ensure that the object attached to an event is relevant to the two chains the supervisor is responsible for.TODO
Object
assigned to an event is relevant for the pair of chains the supervisor is responsible for.For contributor use:
docs/
) and code comments.Files changed
in the Github PR explorer.