-
Notifications
You must be signed in to change notification settings - Fork 45
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
block numbers in arbitrum deployment appear bugged #249
Comments
That's not actually a bug, but an intended feature. |
On the mainnet deployment, its possible to query allocations, take the closedAtBlockNumber, and then query something like delegatedStaked where block=closedAtBlockNumber. This is not possible for arbitrum allocations with the feature as youve described., because the block number in the where clause is the arbitrumBlockNumber not the L1 block. Would you consider including the arbitrumBlockNumber as an additional valuable field in this schema? Or can you recommend a way to look up arbitrum block number by timestamp or something? (also note that arbitrum block number is distinct from L2 block number per these docs: https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/block-numbers-and-time) |
If you are trying to use the block number (L1 block number) to run time-travel queries, then yeah, it's not gonna work as you expect it. BTW, when we talk about L1 block number, we are talking about the L1 block number that's currently accesible in L2 (what the docs you linked call L2 |
Not sure when we could release this though, as we are quite busy trying to ship other features. |
ok, I will eagerly await whenever its able to be prioritized, thanks! |
when querying allocations from https://thegraph.com/hosted-service/subgraph/graphprotocol/graph-network-arbitrum - the fields createdAtBlockNumber and closedAtBlockNumber appear to return invalid values - e.g. this result:
"allocations": [
{
"id": "0x0001b044ebd481afef0545f431fe275980e69e09",
"createdAtBlockNumber": 18176693,
"createdAt": 1695207989
},
that timestamp is for today, but that blocknumber was in 2022 on arbitrum
Can anyone from the foundation plz advise? I believe this is a bug in the subgraph
The text was updated successfully, but these errors were encountered: