eth_getLogs returns error: -32000: Block height must be specified

[rjx18]

Hello again! I'm trying to retrieve logs for events emitted by my smart contract, and this is what I am calling with ethers:

const filter = FACTORY_CONTRACT.filters.EventCreate(account, null);
const logs = await FACTORY_CONTRACT.queryFilter(filter, 0, "latest");
console.log(logs)

However, the RPC adaptor seems to be throwing this error instead:

INFO[1871] eth_getLogs called, fromBlock: 0x0, toBlock: latest, address: 0x11af5e52989cdd566ad60a8966b6be12d6d6fcf7, blockHash: 0x0000000000000000000000000000000000000000000000000000000000000000, topics: [0x4f6315262068043110f08ded2fb22695a25b3bb03e903990fc81a0d3fedb9bb9 0x0000000000000000000000007825110a6a33113978d54bbf1aad6383b094008c]  prefix=ethrpc
INFO[1871] blockStart: 0, blockEnd: 688746               prefix=ethrpc
WARN[1871] eth_getLogs, theta.GetBlocksByHeight returned error: theta RPC returns an error: -32000: Block height must be specified  prefix=ethrpc
WARN[1873] eth_getLogs, theta.GetBlocksByHeight returned error: theta RPC returns an error: -32000: Block height must be specified  prefix=ethrpc
WARN[1877] eth_getLogs, theta.GetBlocksByHeight returned error: theta RPC returns an error: -32000: Block height must be specified  prefix=ethrpc
...

Any idea what might be going wrong here? Thank you!

[jieyilong]

From the adapter logs, it seems like the client code is trying to query for a big range of blocks (from height 0 to the "latest", i.e height 688746). Currently the RPC adapter doesn't have good support for such a big range yet. In the following line, could you change the starting block height to the latest height right before the client submits the transaction?

await FACTORY_CONTRACT.queryFilter(filter, 0, "latest")

[rjx18]

Hello again! Yes you are right, querying from a nearby block to the latest block returns correctly. Getting logs from about 30k blocks back is rather slow, but still eventually returns the logs. However, this wouldn't be good for tracking say NFT ownership. Is there any other way to track which NFTs an account currently owns, without searching through the logs?

[jieyilong]

Yes, the RPC adapter wasn't designed for the NFT ownership tracking purpose. There are two options I'd recommend:

1) Store the NFT ownership info in a DB. You'd also need to write a crawler to extract the NFT transfer events. For example, the crawler can query the eth_getLogs RPC API every 6 seconds (i.e. one block interval) to get the lastest NFT transfer events since the last query. If any NFT transfer happened, update the DB accordingly.

2) Since Theta is EVM compatible, instead of writing your own crawler and DB, you can use also the Graph indexer as your backend. Below are a few good references: https://www.youtube.com/watch?v=l2rzT_Dp4T0 https://github.com/graphprotocol/ethdenver-dapp https://github.com/Uniswap/v2-subgraph

[rjx18]

I see, thanks for the recommendation! I’m currently using a reverse mapping in the smart contract to track this ownership information, and updating it accordingly in each of the smart contract functions. Would this be a bad approach? Thank you!

[jieyilong]

I see. It might increase the gas fee slightly but should also work. There is also the scalability implication -- it might be easier to scale a DB or "the Graph" based backend to handle high volume of ownership queries. But I guess maybe you can start with the smart contact based approach, and upgrade the backend when needed as the user base grows.

[rjx18]

I see, that makes sense. I like the Graph based approach, however, I am trying to run a graph node on my local Theta RPC endpoint, using the following command: cargo run -p graph-node --release -- --debug --postgres-url postgresql://postgres:[PASSWORD]@192.168.0.32:5432/graph-node --ethereum-rpc theta:http://127.0.0.1:18888/rpc --ipfs 127.0.0.1:5001

However, it seems to not be able to communicate with the RPC properly:

Oct 05 12:47:47.272 INFO Connecting to Ethereum to get network identifier, capabilities: archive, traces, provider: theta-rpc-0
Oct 05 12:47:47.273 TRCE Run with retry: net_version RPC call, provider: theta-rpc-0
Oct 05 12:47:47.274 TRCE Run with retry: eth_getBlockByNumber(0, false) RPC call, provider: theta-rpc-0
Oct 05 12:50:17.584 DEBG Trying again after eth_getBlockByNumber(0, false) RPC call timed out (attempt #1), provider: theta-rpc-0
Oct 05 12:50:17.586 ERRO Connection to provider failed. Not using this provider, error: deadline has elapsed, provider: theta-rpc-0
Oct 05 12:50:17.587 ERRO No store configured for Ethereum chain theta; ignoring this chain

Looking at the RPC logs, it did call the following RPC calls:

INFO[4852] web3_clientVersion called                     prefix=web3rpc
INFO[4852] net_version called                            prefix=netrpc
INFO[4852] eth_getBlockByNumber called, blockHeight: 0x0  prefix=ethrpc
INFO[4852] eth_chainId called

Not sure if you have successfully ran a Graph node on the Theta RPC before? If so, could you advice on what may be wrong? Else, I will ask the Graph discord for help, perhaps they know better.

[rjx18]

Hello, again, just an update, it seems like if i run the Graph node with the Theta mainnet RPC endpoint (theta:https://eth-rpc-api.thetatoken.org/rpc) it works as expected.

Any idea why the local private RPC endpoint does not work? Is the local privatenet a full archive node? It would be very much helpful if I can test everything locally for now. Thank you!

[jieyilong]

Got it. If you are using the pre-compiled adapter binary, there might be a few recent fixes not yet included. We'll update the precompiled binary soon. Before that, you may compile the adapter from the source code to use the latest features:

https://docs.thetatoken.org/docs/compile-the-ethereum-rpc-api-from-source-code

[rjx18]

I am using my own compiled version of the source. I suspect it is because the local privatenet is not a full archive node. But that is okay, I will use the testnet RPC for now. Closing this issue, thanks for all the help!