Skip to content
This repository was archived by the owner on Feb 23, 2023. It is now read-only.

Conversation

fordN
Copy link
Contributor

@fordN fordN commented Jun 25, 2020

This PR contributes to the new feature that allows subgraph developers to choose between different Ethereum block structs to use as the input argument to a block handler mapping function.

New Ethereum block types are included in the Ethereum module: FullBlock, FullBlockWithReceipts, and TransactionWithReceipt

Copy link

@That3Percent That3Percent left a comment

Choose a reason for hiding this comment

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

Non-critical comments only

/**
* An Ethereum block with transactions.
*/
export class FullBlock {

Choose a reason for hiding this comment

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

Why not less boilerplate with:

export class FullBlock extends Block {
   transactions: Array<Transaction>
}

The same trick applies to the other classes that have been introduced. I'm a fan of using interfaces for consistency personally, but don't feel the urge to evangelize it too much today. Here's what that would look like (if I remember correctly, my TS is rusty... lol):

export type FullBlock = Block & {
   transactions: Array<Transaction>,
}

One nice thing about interfaces here is that if TransactionWithReceipt implements Transaction then FullBlockWithReceipts also implements FullBlock. Type/Interface compatibility isn't a huge concern for this use-case, but it's interesting to discuss.

@fordN fordN force-pushed the ford/update-blockhandler-input-data branch from 697aa48 to 5b4b1b6 Compare July 16, 2020 16:30
@zinootje
Copy link

zinootje commented Jan 11, 2021

the logs parameter (logs: Array - Array of log objects, which this transaction generated ) which is part of the transaction receipt is missing from the TransactionWithReceipt type . Could you maybe consider adding this ?

@leoyvens
Copy link
Collaborator

Hi @zinootje, because logs are the largest part of a receipt, for performance and operating cost reasons they are deliberately left out here. We're designing this so that it is possible for us to add the option of retrieving the receipts with logs. What is your use case for this?

@zinootje
Copy link

zinootje commented Jan 11, 2021

Hi @leoyvens, thanks for the quick response . I am trying to make a subgraph on a dex aggregator. I watch for the event the dex aggregator contract emits on a swap and then i would parse logs of the transaction to see which protocols are used an how. For example if the Dex agregator uses uniswap there will be a event emitted by the uniswappool contract , if it uses bancor a event emited by the bancor poolcontract , ... .
I think just a option to get the logs of a transaction would be really useful for a lot of use cases it doesn't necessarily need to be added to the Transaction type.

@franz101
Copy link

franz101 commented May 7, 2022

Whats the status here?

@azf20
Copy link

azf20 commented May 9, 2022

Hey @zinootje your request is supported now in graphprotocol/graph-node#3373 (thanks @tilacog )
@franz101 we are not working to add receipts to blocks right now, do you have a specific use case in mind?

@leoyvens
Copy link
Collaborator

@leoyvens leoyvens closed this May 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants