Content
@
https://opensea.io/collection/evm-6
0 reply
0 recast
2 reactions
✳️ dcposch
@dcposch.eth
How do I know, via RPC, that I have all logs up thru block X? eth_getLogs and _getFilterLogs doesn’t seem to do this… give it a toBlock in future and it still returns (necessarily partial) results
1 reply
0 recast
2 reactions
Scott Sunarto
@scott
hmm.. would need to learn more about your node setup. i think alchemy/infura have # of logs limit and sometime would silently drop logs. if you are running your own node, i'd check for config that silently prune historical logs or limit # of logs on eth_getLogs
1 reply
0 recast
0 reaction
✳️ dcposch
@dcposch.eth
Not about pruning old logs, more about making sure you have the latest. I want to write a function that returns “here’s your current balance, and all new transfers that went into that balance” Seems like a common use case!
1 reply
1 recast
1 reaction
Scott Sunarto
@scott
try passing "latest" to `toBlock` is this what you are looking for? fwiw, you probably want an indexer (checkout https://ponder.sh/) to do the heavy lifting here by sifting through all new incoming blocks. could also be fun to write your own!
1 reply
0 recast
0 reaction
✳️ dcposch
@dcposch.eth
Yes this is for my indexer The trouble is - Call eth_call with “latest” to get the current balance - Call eth_logs “latest” for logs No guarantee that they match! You might be missing a transfer needed to explain the balance.
3 replies
0 recast
0 reaction
✳️ dcposch
@dcposch.eth
So what if you fetch the latest block first , then pass that block number explicitly to eth_call and _getLogs? As far as I can tell , eth_logs will return successfully and still not guarantee that it actually has all logs thru that block. Wack
3 replies
0 recast
1 reaction
0xdapper
@0xdapper
Isn't it okay to assume if it had the latest block(which we know it did because of the response) it should have all the logs until then too?
1 reply
0 recast
0 reaction
✳️ dcposch
@dcposch.eth
Public RPCs load balance between multiple backends, so I think not. The JSON RPC could use and upgrade (backwards compatible ofc, just one or two new and better functions). My sense is the original spec was designed quickly, long ago, with the assumption of a single local node
0 reply
0 recast
0 reaction
