-
Notifications
You must be signed in to change notification settings - Fork 10
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
Missing Block Fields #145
Comments
@jribbink great call out |
@sideninja I noticed this was merged 4 days ago, are we able to deploy this? There seems to be a bug related to hardhats ignition deployer that this might solve 👍 thanks! |
@ianthpun yes we did deploy today. Sorry was busy with some other stuff. |
Can confirm this fixed |
Will close, feel free to reopen if something new is discovered |
@sideninja I have got this working, see comment. This is not related to any missing block fields, but a condition on confirmations that hardhat ignition performs. So I am going to close this. |
Problem
I apologize in advance if this issue is already on the radar/tracked somewhere, but I couldn't find it.
This is tangential to the issue submitted yesterday #137. The fields returned from the
eth_getBlockByHash
ð_getBlockByNumber
responses are somewhat limited & are not satisfactory for some clients.There are a number of fields missing from the spec, but in particular,
ethers
will fail unless the following fields are added to the response:timestamp
difficulty
gasLimit
gasUsed
extraData
I think this is probably because these values are parsed by
ethers
, so undefined throws off the library (and others missing fields are not parsed, so they don't cause any immediate issues when making this query). The availability of these fields would fixethers.getBlock
calls, but I am unsure if any other incorrect/missing fields I didn't mention will still cause issues with other parts of theethers
API.In general, I think it would be ideal if the
Block
model were at least populated with empty values (if it is not easy/possible to provide a value for these missing fields) so that clients can still parse this data without throwing errors.Steps to Reproduce
(note: you will have to be using the current
flow-evm-gateway
, not the live, deployed one because you will end up seeing #137 instead)Acceptance Criteria
Minimum, these fields listed exist in some capacity. But it is probably ideal to at least provided empty values for other fields, as mentioned, to protect against future issues.
Context
Blocking integration with clients/writing docs.
The text was updated successfully, but these errors were encountered: