Open rvagg opened 3 days ago
@rvagg Proposed a solution for this at https://filecoinproject.slack.com/archives/CP50PPW2X/p1729778184348849.
Some thoughts I jotted down in that thread, here for the record:
raw
is a good first pass at tackling this, it would certainly help with eth API performance and get us closer to fixing this. Probably a good option for an initial pass at this. But it doesn't solve the problem completely.raw
entries and don't match that schema, it would be weird, but not out of the question.maxResults
instead of having maxResults
applied at the bottom layer and a second filter trimming them down at an upper layer. If we had an optional function to filter by in this block then we could achieve that: https://github.com/filecoin-project/lotus/blob/703333c8b4d1fd15dffa9fc7d0339b28841f5c90/chain/events/filter/index.go#L528-L562 (ChainIndexer has a similar block of code).I also think we should error in the eth APIs if we go over max, not having a signal for users makes for a big footgun. But let's deal with that separately.
@rvagg @akaladarshi
A great first step that will get us most of the way there is to add a "filter for Raw codec" condition to every query made by all the ETH Event APIs.
Noticed by @ArseniiPetrovich:
and
i.e. extending the range of epochs while leaving the start of the range static drops events from the front of the list.
This is because we apply
MaxFilterResults
max (the invisible cap) before filtering for eth events, not after.For that same block range:
10000
is the default value forMaxFilterResults
.MaxFilterResults
. The fact that you can't know is a big problem. The best signal you have is if you hit 10,000 events returned. I'd like to build pagination intoGetActorEvents
(maybe notRaw
) but we can't do that for eth APIs, the user has to have a clear way of knowing that they need to craft finer filters. go-ethereum might have a precedent here that we should investigate.