You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our dApp stopped working once we tested it against a recently deployed tenderly fork.
After spending some hours trying to find the root cause, it turns out that the problem is that some of the calls that metamask makes to eth_getLogs (as a result of a logs subscription) have an invalid payload.
An example of an invalid payload produced from metamask in order to query the logs of the newest block:
At a first glance everything looks fine. However, if we pay closer attention to the fromBlock field we will notice that it has an invalid leading zero, which causes the node to reject the request due to invalid parameters.
My guess is that this issue doesn't come up very often b/c most nodes must tolerate invalid "Quantity" fields. However, according to the official spec:
When encoding quantities (integers, numbers): encode as hex, prefix with "0x", the most compact representation (slight exception: zero should be represented as "0x0").
Another reason why I think that this issue doesn't come up often is because I've noticed that most of the times that the queries are created, the quantity fields come from the result of other requests, which are returning properly encoded Quantity fields.
The text was updated successfully, but these errors were encountered:
Hi and thank you for maintaining this library!
Our dApp stopped working once we tested it against a recently deployed tenderly fork.
After spending some hours trying to find the root cause, it turns out that the problem is that some of the calls that metamask makes to
eth_getLogs
(as a result of alogs
subscription) have an invalid payload.An example of an invalid payload produced from metamask in order to query the logs of the newest block:
At a first glance everything looks fine. However, if we pay closer attention to the
fromBlock
field we will notice that it has an invalid leading zero, which causes the node to reject the request due to invalid parameters.My guess is that this issue doesn't come up very often b/c most nodes must tolerate invalid "Quantity" fields. However, according to the official spec:
Another reason why I think that this issue doesn't come up often is because I've noticed that most of the times that the queries are created, the quantity fields come from the result of other requests, which are returning properly encoded Quantity fields.
The text was updated successfully, but these errors were encountered: