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

Hypersync source support #103

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

SozinM
Copy link

@SozinM SozinM commented Sep 16, 2024

This Pr adds hypersync integration to the rindexer.
Initially i made it with enum, but i think that dynamic dispatch fits better here. We need to choose instance during runtime via config.

This is p1 of the changes, would be nice to move streaming logic to another trait/extend current one, to be able to specialize streaming based on the upstream.

Copy link

vercel bot commented Sep 16, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
rindexer-documentation ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 1, 2025 2:12am

@SozinM SozinM marked this pull request as draft September 16, 2024 06:08
@SozinM SozinM changed the title Hypersync support Hypersync source support Sep 16, 2024
@SozinM
Copy link
Author

SozinM commented Sep 16, 2024

Hi @joshstevens19
I'm implementing hypersync support for rindexer and want to ask you opinion on using enum/dyn Trait for provider selection.
Now I've implemented a simple enum approach, but it would be quite easy to switch to dyn Trait

@joshstevens19
Copy link
Owner

joshstevens19 commented Sep 16, 2024

Hi @joshstevens19 I'm implementing hypersync support for rindexer and want to ask you opinion on using enum/dyn Trait for provider selection. Now I've implemented a simple enum approach, but it would be quite easy to switch to dyn Trait

Thanks for this i think how you done it is pretty good i was hoping to also extend this to support ExEx on reth later on (but that's for a later thought) but as dyn trait add runtime costs due to dynamic dispatcher vs enum which uses static dispatcher (which is faster) lets pick performance here so what you done IMHO is good - thoughts? if you are in agreement il do a PR review once its out of draft and rebased.

If you can also add to the docs for this once done as well to say we support hypersync endpoints

@SozinM
Copy link
Author

SozinM commented Oct 8, 2024

Hi @joshstevens19
I think it's ready for review, had little fight with playground autogen :)
In this implementation dyn traits doesn't add much overhead (compared with enums as they will need vtable)
Example working, alingside with tests. Current implementation doesn't bring much benefit speedwise but would once we specialize streaming.
Also other providers could start implement additional traits.

@joshstevens19
Copy link
Owner

thanks @SozinM i actually made a slight change today to provider to expose block timestamp do you want to rebase to resolve - d1683fb ? will take a look at this PR tomorrow good work

@@ -26,11 +26,14 @@ it then ask you 2 questions:
networks:
- name: ethereum // [!code focus]
chain_id: 1
kind: Rpc
Copy link
Owner

Choose a reason for hiding this comment

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

i wouldnt change the rindexer yaml i would work this out under the hood basically if rpc .includes hypersync then you know its turned on

Copy link
Author

Choose a reason for hiding this comment

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

i could make default kind = Rpc, so we won't change default rindexer yaml. But considering other impls in the future (exex, sqd) it better to specify it trough param

Copy link
Owner

Choose a reason for hiding this comment

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

yeah ok we can make it default RPC and then not add it to all examples but just have 1 example of how to enable it for hypersync?

.map_err(|err| ProviderError::CustomError(err.to_string()))
}

async fn get_logs(&self, filter: &RindexerEventFilter) -> Result<Vec<Log>, ProviderError> {
Copy link
Owner

Choose a reason for hiding this comment

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

i did comment this but worth looking at this d1683fb as we exposed a new log type to expose the block timestamp


async fn get_block_number(&self) -> Result<U64, ProviderError>;

async fn get_logs(&self, filter: &RindexerEventFilter) -> Result<Vec<Log>, ProviderError>;
Copy link
Owner

Choose a reason for hiding this comment

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

@@ -15,8 +19,8 @@ contracts:
details:
- network: ethereum
address: 0xae78736cd615f374d3085123a210448e74fc6393
start_block: '18600000'
end_block: '18718056'
start_block: '11600000'
Copy link
Owner

Choose a reason for hiding this comment

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

revert?

"/Users/joshstevens/code/rindexer/rindexer_rust_playground/rindexer.yaml",
)
.expect("Invalid path");
let path = PathBuf::from_str("./rindexer.yaml").expect("Invalid path");
Copy link
Owner

Choose a reason for hiding this comment

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

thx lol full path 😛

@@ -11,6 +17,8 @@ pub struct Network {

pub rpc: String,

pub kind: ProviderType,
Copy link
Owner

Choose a reason for hiding this comment

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

yeah defo not keen on this approach would rather auto work it out by rpc URL IMHO

Copy link
Author

Choose a reason for hiding this comment

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

i could think only about 2 options:

  1. Deduce type based on url
  2. Implicitly specify it
    First have the problem that it could fail for no apparent reason (change from using https://1.hypersync.xyz to localproxy/kubernetes service name will break it silently with no way to fix it unless code is changed)
    Second is too verbose

Wdyt about combining approaches -> We deduce from url if no kind provided?

Copy link
Owner

Choose a reason for hiding this comment

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

yeah ok we can make it default RPC and then not add it to all examples but just have 1 example of how to enable it for hypersync?

@SozinM SozinM force-pushed the feature/hypersync-support branch from fb388f9 to 5677c19 Compare October 15, 2024 17:07
@joshstevens19
Copy link
Owner

Thanks a lot I’m currently on annual leave till 28th but once back we can get this in 💪💪

@SozinM
Copy link
Author

SozinM commented Oct 21, 2024

@joshstevens19
Sorry, i'm procrastinating to do final touches, but overall it should work now
Will push to complete this before you are back :)

@joshstevens19
Copy link
Owner

hey is this complete @SozinM ?

@SozinM
Copy link
Author

SozinM commented Oct 30, 2024

Hi @joshstevens19 yes, should be good now

@@ -43,6 +43,7 @@ project_type: no-code
networks:
- name: ethereum
chain_id: 1
kind: Rpc
Copy link
Owner

Choose a reason for hiding this comment

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

no need for this if fallbacks to RPC (same for all below here)

@@ -31,6 +31,16 @@ networks:

This will skip for you if you only have one network setup.

By setting kind to "Hypersync" you could use [hypersync](https://docs.envio.dev/docs/HyperSync/overview) as a data source.
Copy link
Owner

Choose a reason for hiding this comment

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

hmm need to think about the best place for this callout

@joshstevens19
Copy link
Owner

ok going to need to do some manual tests on this over weekend and make sure all good if so can deploy do want to fix some of the documentation call outs etc - nice job @SozinM

@joshstevens19
Copy link
Owner

joshstevens19 commented Dec 26, 2024

So sorry guys will review this tomorrow/Monday and test it out then merge it good fully forgot 🙏

@joshstevens19
Copy link
Owner

joshstevens19 commented Dec 28, 2024

hey when i build this locally i get

error: failed to run custom build command for `hypersync-net-types v0.9.0`

Caused by:
  process didn't exit successfully: `/Users/joshstevens/code/rindexer/target/debug/build/hypersync-net-types-b32cc79a337da369/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at /Users/joshstevens/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hypersync-net-types-0.9.0/build.rs:5:10:
  compiling schema: Error { kind: Failed, extra: "Failed to execute `capnp --version`: No such file or directory (os error 2). Please verify that version 0.5.2 or higher of the capnp executable is installed on your system. See https://capnproto.org/install.html" }
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
joshstevens@AMWM-G2136D03XG rindexer % 

@SozinM

its trying to run a build.rs of:

fn main() {
    capnpc::CompilerCommand::new()
        .file("hypersync_net_types.capnp")
        .run()
        .expect("compiling schema");
}

we shouldnt have to install capnp locally or on machine to make work imho - how could we fix this?

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.

2 participants