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

Explorer crate #3350

Merged
merged 54 commits into from
Mar 9, 2022
Merged

Explorer crate #3350

merged 54 commits into from
Mar 9, 2022

Conversation

ecioppettini
Copy link
Contributor

@ecioppettini ecioppettini commented Jun 3, 2021

see #3227

the reason the CI fails should be solved by #3595

also, this is (re?)based on top of #3662 , that one should be merged first.

this PR:

  • removes the explorer module from jormungandr
  • moves the implementation to a new crate in the workspace
  • changes the explorer_sanity_test in the integration tests to launch an explorer and test against it so it keeps working.
  • adds a simple 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.

@ecioppettini ecioppettini self-assigned this Jun 3, 2021
@ecioppettini ecioppettini mentioned this pull request Jun 25, 2021
@ecioppettini ecioppettini force-pushed the explorer-crate branch 2 times, most recently from e3c580b to 54297c5 Compare September 17, 2021 20:21
@ecioppettini ecioppettini force-pushed the explorer-crate branch 2 times, most recently from 2ae0fb2 to 78c28b0 Compare October 20, 2021 02:13
@ecioppettini ecioppettini changed the base branch from notifier-grpc to master October 20, 2021 02:15
@ecioppettini ecioppettini marked this pull request as ready for review November 26, 2021 14:36
Copy link
Contributor

@zeegomo zeegomo left a 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/api/graphql/mod.rs Show resolved Hide resolved
explorer/src/api/graphql/scalars.rs Show resolved Hide resolved
explorer/src/api/mod.rs Outdated Show resolved Hide resolved
explorer/src/api/mod.rs Show resolved Hide resolved
@@ -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();
Copy link
Contributor

Choose a reason for hiding this comment

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

What about public votes?

Copy link
Contributor Author

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/db/tally.rs Outdated Show resolved Hide resolved
explorer/src/db/tally.rs Show resolved Hide resolved
explorer/src/logging.rs Show resolved Hide resolved
let successful = self.db.set_tip(tip).await;

if !successful {
let mut guard = self.tip_candidate.lock().await;
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@eugene-babichenko eugene-babichenko added the A-explorer Area: Explorer API and backend label Dec 8, 2021
Copy link
Contributor

@zeegomo zeegomo left a 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

explorer/Cargo.toml Show resolved Hide resolved
explorer/src/api/graphql/certificates.rs Outdated Show resolved Hide resolved
explorer/src/api/graphql/certificates.rs Outdated Show resolved Hide resolved
explorer/src/db/mod.rs Outdated Show resolved Hide resolved
explorer/src/db/mod.rs Outdated Show resolved Hide resolved
explorer/src/db/mod.rs Outdated Show resolved Hide resolved
explorer/src/db/mod.rs Outdated Show resolved Hide resolved
explorer/src/db/persistent_sequence.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@zeegomo zeegomo left a 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!

Copy link
Contributor

@eugene-babichenko eugene-babichenko left a 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"
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@eugene-babichenko
Copy link
Contributor

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"),
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@eugene-babichenko
Copy link
Contributor

And don't forget to add the changelog entry :)

ecioppettini and others added 27 commits March 7, 2022 14:40
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
@ecioppettini ecioppettini merged commit acf37fe into master Mar 9, 2022
@ecioppettini ecioppettini deleted the explorer-crate branch March 9, 2022 13:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-explorer Area: Explorer API and backend
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants