implemented getTransactionReceiptByHash #99
Conversation
[Change] - added config file to auto generate types from graphql schema - added helper function to provide query functions to interact with evm-subql - implemented getTransactionReceiptByHash function which uses the above helper function to fetch data from evm-subql [Test] - for query helpers, added a couple unit tests - for eth-rpc-adaptor, ran it and tested a couple queries to make sure they return correct result.
shunjizhan
changed the title
| // TODO: correct values of these? | ||
| const confirmations = 0; | ||
| const effectiveGasPrice = BIGNUMBER_ONE; | ||
| const byzantium: false = false; |
There was a problem hiding this comment.
do we need those?
I am looking at https://infura.io/docs/ethereum/json-rpc/eth-getTransactionReceipt
Also can check https://github.com/paritytech/frontier/blob/master/client/rpc-core/src/types/receipt.rs#L26
| return { | ||
| to: tx.to || defaultAddress, | ||
| from: tx.from, | ||
| contractAddress: tx.contractAddress || defaultAddress, |
There was a problem hiding this comment.
according to https://infura.io/docs/ethereum/json-rpc/eth-getTransactionReceipt it should be null if no contractAddress
the contract address created, if the transaction was a contract creation, otherwise - null.
| const defaultAddress = '0x'; | ||
|
|
||
| return { | ||
| to: tx.to || defaultAddress, |
There was a problem hiding this comment.
according to https://infura.io/docs/ethereum/json-rpc/eth-getTransactionReceipt it should be null if no to
address of the receiver. Null when the transaction is a contract creation transaction.
There was a problem hiding this comment.
yeah but this would conflict with the type library we use:
https://github.com/ethers-io/ethers.js/blob/b1458989761c11bf626591706aa4ce98dae2d6a9/packages/abstract-provider/src.ts/index.ts#L106
according to it, to and contractAddress should both the string, also confirmations, effectiveGasPrice, byzantium are required.
Is there a more accurate lib that reflect EVM types? Or should we overwrite @etherproject to make the type match infura?
There was a problem hiding this comment.
maybe we should use the parity frontier lib as our type definition? Is there a TS lib with it?🤔
There was a problem hiding this comment.
The infura definition seems to be the same as eth wiki, but don't know why @ethersproject definition is so different from them... Opened a discussion there but no one answered
ethers-io/ethers.js#2270
There was a problem hiding this comment.
ok. I am ok with the current code until something else complains it needs to be null.
can you write an issue and we can merge this
There was a problem hiding this comment.
sounds good! Created a new issue #100 to address this
Change
Test
:8545and they returned correct result.