nlordell / ethrpc-rs Goto Github PK

If possible, TransactionKind and TransactionReceiptKind should be one and the same - whether it is possible depends on what additional fields they carry.

There have been a few new methods introduced recently. Enough to warrant a new release!

I can see that you are trying to separate the Transaction type from the before it is actually mined, by excluding things like block_number

However this rpc endpoint to fetch hydrated block returns transactions containing block_numbers:

curl -X POST $NODE_URL --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xffff1f", true],"id":1}' | jq '.result.transactions'

unfortunately this data is being lost in transmission.

I believe it should be Optional field (since its None when pending)

While the docs specify that hydrated blocks return "Signed Transaction" types (excluding the hash) it turns out that this method actually returns the hash:

Request:

curl -X POST $NODE_URL --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x119f996", true],"id":1}' | jq

Response: http://jsonblob.com/1173956359015489536

We notice that the hash field is missing from SignedTransaction type here.

I suspect that the docs are outdated or incorrect. As far as I can tell, this is the only missing field. Will create a PR adding it.

The transaction Responses return both fields "yParity" and "v" (which are equivalent).

Observe the difference in data for this request:

curl -X POST $NODE_URL --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xe4e364", true],"id":1}' | jq '.result.transactions[0]'

when NODE_URL is ankr node vs quicknode or infura. Ankr returns a parsable response while the other two have "conflicting fields".

This is likely due to this:

  /// Y parity of the signature.
  #[serde(alias = "v")]
  pub y_parity: YParity,

Is there some way to intercept serde to remove the conflicting fields in the response before parsing? It seems that this will need to be handled here since there are multiple nodes returning this data.

Brought up also in #9