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
The result of that PR is that calls where only state_reverted is true are still processed as successful calls because both status_reverted and status_failed are false. This goes against the explanation for that field in the firehose proto spec.
Test case: a call from this transaction is present in the linked subgraph (in the liquidityChanges table) despite both calls to our contract having their state changes reverted (but only the second call has status_failed=true).
Is there a reason for this behavior? Shouldn't this line also have a !call.state_reverted condition?
Or is there a different way to filter out state_reverted=true calls?
Bug report
This is in reference to issue #3701 and the PR #3762 that was meant to address it when the firehose is used. In that PR the following is written:
That change was implemented, but then it was immediately undone to "align firehose with RPC behavior" (which previous discussions established is incorrect and potentially unfixable).
The result of that PR is that calls where only
state_reverted
istrue
are still processed as successful calls because bothstatus_reverted
andstatus_failed
arefalse
. This goes against the explanation for that field in the firehose proto spec.Test case: a call from this transaction is present in the linked subgraph (in the
liquidityChanges
table) despite both calls to our contract having their state changes reverted (but only the second call hasstatus_failed=true
).Is there a reason for this behavior? Shouldn't this line also have a
!call.state_reverted
condition?Or is there a different way to filter out
state_reverted=true
calls?Relevant log output
IPFS hash
No response
Subgraph name or link to explorer
https://thegraph.com/explorer/subgraphs/DyHaLYK1keqcv3YD3VczKGYvxQGfGgV6bGTbZLMj5xME
Some information to help us out
OS information
None
The text was updated successfully, but these errors were encountered: