Background
During review of PR #7172 (#7172), a question was raised about the behavior of eth_getFilterLogs vs eth_getFilterChanges.
Standard Ethereum spec defines:
eth_getFilterChanges — incremental/polling; returns only logs since the last poll (stateful).eth_getFilterLogs — returns all logs matching the filter at the time of the call, regardless of previous polls (idempotent/non-stateful).
Lotus behavior (observed in node/impl/eth/events.go):
Both EthGetFilterLogs and EthGetFilterChanges call fc.TakeCollectedEvents(ctx), which drains the filter's accumulated event list. This makes both methods stateful and incremental — a deliberate (or accidental?) deviation from the standard Ethereum spec.
Forest's current behavior (after PR #7172):
Forest mirrors Lotus by using a shared poll_event_filter helper for both methods, making both stateful/incremental.
Question
Is the Lotus behavior intentional (i.e., Filecoin/Lotus defines its own semantics for eth_getFilterLogs) or is it a bug in Lotus?
Concretely, consider this sequence:
1. eth_getFilterChanges → returns [log A, log B], poll state updated
2. eth_getFilterLogs → returns [] (A and B already consumed!) ← is this correct?
According to the Ethereum spec, step 2 should return [log A, log B], but both Lotus and Forest currently return [].
Action Items
References
Background
During review of PR #7172 (#7172), a question was raised about the behavior of
eth_getFilterLogsvseth_getFilterChanges.Standard Ethereum spec defines:
eth_getFilterChanges— incremental/polling; returns only logs since the last poll (stateful).eth_getFilterLogs— returns all logs matching the filter at the time of the call, regardless of previous polls (idempotent/non-stateful).Lotus behavior (observed in
node/impl/eth/events.go):Both
EthGetFilterLogsandEthGetFilterChangescallfc.TakeCollectedEvents(ctx), which drains the filter's accumulated event list. This makes both methods stateful and incremental — a deliberate (or accidental?) deviation from the standard Ethereum spec.Forest's current behavior (after PR #7172):
Forest mirrors Lotus by using a shared
poll_event_filterhelper for both methods, making both stateful/incremental.Question
Is the Lotus behavior intentional (i.e., Filecoin/Lotus defines its own semantics for
eth_getFilterLogs) or is it a bug in Lotus?Concretely, consider this sequence:
According to the Ethereum spec, step 2 should return
[log A, log B], but both Lotus and Forest currently return[].Action Items
eth_getFilterLogs.References
node/impl/eth/events.go—EthGetFilterLogsandEthGetFilterChanges