Felix Lange
Felix Lange
We have already explained our view on this PR. It seems like a nice idea, and we are interested to see if it will work. The best way to prove...
GraphQL requests are parsed here: https://github.com/ethereum/go-ethereum/blob/13ef21d4672742e805316df9f319d51e749a129d/graphql/service.go#L45 Instead of trying to make it work with `float64`, we could also call [`UseNumber`](https://pkg.go.dev/encoding/json#Decoder.UseNumber) on the decoder before using it. That would allow arbitrary-size...
Could you explain the question a bit more? I don't know what @dserdiuk means in his comment.
@holiman #26984 does not exist
Thanks for clarifying the question. go-ethereum definitely assumes a store ordered by key and some things will not work without this property.
Not even just serving, some of the other snapshot operations such as snapshot-to-trie also require iterating the keyspace, and a particular order is expected. We will use this property even...
This should be ready for merging now!
Suggested merging date: Feb 6 2024
I like this, but would prefer not to have the `NewMessage` constructor. We will for sure have to add/change parameters of this function in the future. If they are passed...
Sorry, I will get to re-reviewing this PR soon!