-
Notifications
You must be signed in to change notification settings - Fork 132
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
Explorer crate #3350
Explorer crate #3350
Conversation
b95cab0
to
68764c7
Compare
e0b006a
to
44efd96
Compare
bcc4e1c
to
50dae54
Compare
3b8f772
to
631ca8a
Compare
e3c580b
to
54297c5
Compare
54297c5
to
f6d9f2c
Compare
2ae0fb2
to
78c28b0
Compare
78c28b0
to
1a0d59a
Compare
290a9c6
to
1160cef
Compare
1160cef
to
46ed8e1
Compare
5d33f2f
to
89f0a43
Compare
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.
First look, looks good overall
explorer/src/db/mod.rs
Outdated
@@ -801,48 +677,22 @@ fn apply_block_to_vote_plans( | |||
} | |||
} | |||
Certificate::VoteTally(vote_tally) => { | |||
use chain_impl_mockchain::vote::PayloadType; | |||
let decrypted_tally = vote_tally.tally_decrypted().unwrap(); |
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.
What about public votes?
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.
I think this should be addressed now
explorer/src/indexer.rs
Outdated
let successful = self.db.set_tip(tip).await; | ||
|
||
if !successful { | ||
let mut guard = self.tip_candidate.lock().await; |
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.
I'm missing a bit of context for this two level tip update
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.
Well, it's kinda hacky I guess.
We don't have any guarantees about the order of events, and if we set a block as the tip, but haven't indexed the block yet, queries in between will fail.
In the past, inside the node, we broadcasted tip updates before broadcasting the blocks. I'm not sure if that changed actually, because I believe you refactored that, but I wanted the explorer to keep working regardless of the order.
And here, because the tip and block subscriptions are different streams, I think it may be possible for this to happen regardless of the order they are emitted in jormungandr.
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.
So db.set_tip
will fail if the block was not indexed yet? I would add a comment explaining this behavior in the code though, as it is not immediate.
PS: I don't remember now if there's a particular order in that, but I would guess tip updates follow block broadcasts.
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.
Well, I changed the return type to a Result<(), BlockNotFound>
instead, as it is a bit more self-documenting.
926a881
to
1a72ae0
Compare
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.
I think there are still some explorer-related files left in the node
testing/jormungandr-integration-tests/src/jormungandr/mempool.rs
Outdated
Show resolved
Hide resolved
217e2e7
to
432c571
Compare
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.
I think this is now in a shape that can go in.
There are parts that could be further polished and/or improved in the implementation, but I'll leave this for future PRs, as it's mostly code we already had.
Good work!
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 in general, but definitely needs a rebase. I was also thinking that some parts (I spotted at least logging, REST API setup and stop signal handler) are basically the same as in jormungandr.
We should probably have a reusable module with these.
serde_yaml = "0.8.13" | ||
structopt = "0.3.15" | ||
thiserror = "1.0.20" | ||
anyhow = "1.0.41" |
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.
Is it used? I would not use anyhow
as we are trying to use thiserror
everywhere for consistency.
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.
Both are used, since I found it quite convenient for the top level (user) errors, in which I only wanted an error message for the user, but it's not strictly necessary.
like, with these things:
let mut client = Client::connect(settings.node.clone())
.await
.context("Couldn't establish connection with node")
.map_err(Error::UnrecoverableError)?;
let sync_stream = client
.sync_multiverse(vec![])
.await
.context("Failed to establish bootstrap stream")
.map_err(Error::UnrecoverableError)?;
let block_events = client
.block_subscription()
.await
.context("Failed to establish block subscription")
.map_err(Error::UnrecoverableError)?;
let tip_events = client
.tip_subscription()
.await
.context("Failed to establish tip subscription")
.map_err(Error::UnrecoverableError)?;
Since they are in the main
function, having enum variants for each case is not really that important (because no one will pattern match on them), and IMO being able to just provide some specific info directly in there makes it easier to provide good error messages since otherwise errors tend to get more generic.
That said, it's certainly possible to achieve the same with just thiserror
, and it's not used extensively, but I don't think they are really alternatives, I feel it's more like a distinction between library errors vs application errors.
testing/jormungandr-testing-utils/src/testing/node/explorer/wrappers.rs
Outdated
Show resolved
Hide resolved
b5dc963
to
81e2b8d
Compare
Gah, there is still one conflicting file. |
@@ -528,7 +511,7 @@ impl From<&ConfigParamLib> for ConfigParam { | |||
Self::TransactionMaxExpiryEpochs(v.into()) | |||
} | |||
#[cfg(feature = "evm")] | |||
ConfigParamLib::EvmParams(v) => Self::EvmParams(v.into()), | |||
ConfigParamLib::EvmParams(_) => unimplemented!("evm support"), |
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.
Are we just going to drop EVM support?
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.
well, not drop it, since but we don't really have support for this in jormungandr either:
fn from(_: &chain_impl_mockchain::config::EvmConfig) -> Self { |
But I will just put the same thing here for consistency and to avoid the panic.
And don't forget to add the changelog entry :) |
this makes the code a bit more self-documenting than with a boolean, even if the error value is not actually used here.
because otherwise the function will panic for public tally, as there is no decrypted tally
it was returning the opposite value
to account for slow IO, or performance issues when running the test
this allows using it in other tests, like in `retire_stake_pool_explorer` and other integration tests
by just panicking, proper suppport can be done later
43f0f58
to
70c6000
Compare
see #3227
the reason the CI fails should be solved by #3595also, this is (re?)based on top of #3662 , that one should be merged first.this PR:
explorer_sanity_test
in the integration tests to launch an explorer and test against it so it keeps working.tally
implementation that doesn't use the ledger (because there is no ledger here). This is mostly to keep the api working without replacing it with an unimplemented error, but it may need a rework later.