-
Notifications
You must be signed in to change notification settings - Fork 978
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
Subgraph Composition: Use Firehose endpoint to load blocks for subgraph triggers #5706
base: krishna/switch-to-using-only-block-ptrs
Are you sure you want to change the base?
Subgraph Composition: Use Firehose endpoint to load blocks for subgraph triggers #5706
Conversation
c6a7960
to
84f4ccb
Compare
84f4ccb
to
a3891bb
Compare
/// Fetches blocks from the cache based on block numbers, excluding duplicates | ||
/// (i.e., multiple blocks for the same number), and identifying missing blocks that | ||
/// need to be fetched via RPC/Firehose. Returns a tuple of the found blocks and the missing block numbers. | ||
async fn fetch_unique_blocks_from_cache( |
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 would be a good candidate to add some unit test coverage
@@ -763,23 +819,96 @@ impl TriggersAdapterTrait<Chain> for TriggersAdapter { | |||
logger: Logger, | |||
block_numbers: HashSet<BlockNumber>, | |||
) -> Result<Vec<BlockFinality>> { | |||
use graph::futures01::stream::Stream; | |||
// Common function to handle block loading, regardless of source | |||
async fn load_blocks<F, Fut>( |
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 there a reason this couldn't be a function on triggers adapter instead of inside the function? This is more of a nitpick but this usually means it's code that cannot be tested and personally I think it makes code less readable. I understand the code locality here and I think it does help understand the full context (in this case). Just wary of doing this sort of thing as a norm
.ok_or(anyhow!("unable to get adapter for is_on_main_chain"))? | ||
.is_on_main_chain(&self.logger, ptr.clone()) | ||
.await | ||
match &*self.chain_client { |
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.
wondering if this should be on the ChainClient, since it's implemented already for rpc adapters, perhaps it would make sense to get the block from the adapter (whichever) and then have the logic on the layer above that makes the decision on whether it is on the main chain.
No description provided.