Pending transactions cannot be retrieved

[woozorg]

Hi,

I'm using ethers.js to connect to a local cronosd node. I am subscribing to pending transactions, and I get a stream of hashes, as expected.

However, when i try to retrieve the transactions based on these hashes, I get null. Upon further inspection, I believe that none of the hashes that I see for the pending transactions are present in the subsequent mined blocks. This works perfectly fine on ETH or BSC.

Is this expected? Is this bug? Are the transaction hashes updated someone when mining?

Thanks

[tomtau]

the root cause may be this: evmos/ethermint#705

[tomtau]

this should fix it: evmos/ethermint#741

[noncetoolow]

I may be missing something, but isn't the problem described in tharsis/ethermint#705 about the index of transactions rather than incorrect transaction hashes?

[yihuang]

Do the transactions get included eventually? I think eth_getTransaction can only find the included transaction, not pending ones.

[noncetoolow]

No, they don't.
eth_getTransaction does return the transaction, but won't return a block number before the transaction has been included. eth_getTransactionReceipt will fail on pending tx.
On a side note: I wasn't able to get any output from any of the txPool functions. It seems like there is something off with the txPool here.

[drbenshiller]

It seems that pending transaction hashes arrive in batches, i.e. as if they are emmited with every new block. Disconnecting and reconnecting to the websocket stops the transaction hash stream altogether. Only restarting cronosd allows for a new subscription.

So far I have not been able to obtain consistent output from the websocket subscription. I tried building cronosd from source. Is there any workaround, i.e. the mentioned fix? How do I include the update for ethermit to compile into cronosd?

[drbenshiller]

I can confirm that the txPool functions don't work as expected, i.e. on a working and synced full node I get:

$ curl -X POST --data '{"jsonrpc":"2.0","method":"txpool_status","params":[],"id":1}' -H "Content-Type: application/json" http://localhost:8545

Output
{"jsonrpc":"2.0","id":1,"result":{"pending":"0x0","queued":"0x0"}}

and:

$ curl --location --request POST 'localhost:8545/' --header 'Content-Type: application/json' --data-raw '{
"jsonrpc":"2.0",
"method":"txpool_content",
"params":[],
"id":83
}'

Output:
{"jsonrpc":"2.0","id":83,"result":{"pending":{},"queued":{}}}

[noncetoolow]

Output {"jsonrpc":"2.0","id":1,"result":{"pending":"0x0","queued":"0x0"}}
and:
Output: {"jsonrpc":"2.0","id":83,"result":{"pending":{},"queued":{}}}

This is the output I was referring to in my previous post. The txPool is unfortunately not useable.

[naovader888]

Hey is some developer interested in joining a project for the Cronos Hackathon yet? please send me a link Discord user maovader888

[sayem314]

How did you enable mempool pending transactions? I cannot find anything in any docs.

[wdragen]

Version 0.6.4 has same problem.
Any update?

[silvercondor]

still getting the issue on 0.6.5

same issue with newHeads where block hash returned is invalid causing eth.getBlockByHash to fail

problem likely with ethermint returning invalid (tendermint?) hash

[redline-finance]

Any updates on this? @yihuang @thomas-nguy

Maybe some guidance so we can fix it ourselves before you push the official fix? Not very familiar with the cosmos SDK or ethermint

[thomas-nguy]

The txpool namespace is not yet implemented on ethermint

https://github.com/tharsis/ethermint/blob/main/rpc/ethereum/namespaces/txpool/api.go

evmos/ethermint#124 (comment)

I would suggest to open an issue on ethermint repository so that we can start a discussion
https://github.com/tharsis/ethermint/issues/new?assignees=&labels=&template=feature-request.md

[redline-finance]

@thomas-nguy it's not that we actually need the JSON-RPC txpool namespace. The eth_subscribe is not part of that txpool and already implemented in cronos. By subscribing to the "newPendingTransactions" we get a stream of hashes. What are these hashes? Why can't we query them using the standard eth_getTransactionByHash?

In tendermint there is this concept of "unconfirmed_txs", but I've tried querying them in cronos and they're always the same and never changing? (i.e. not getting "pending" transactions)

[yihuang]

@thomas-nguy it's not that we actually need the JSON-RPC txpool namespace. The eth_subscribe is not part of that txpool and already implemented in cronos. By subscribing to the "newPendingTransactions" we get a stream of hashes. What are these hashes? Why can't we query them using the standard eth_getTransactionByHash?

In tendermint there is this concept of "unconfirmed_txs", but I've tried querying them in cronos and they're always the same and never changing? (i.e. not getting "pending" transactions)

I couldn't reproduce it, I tried the follow request in websocket API, and sending some transactions to the chain, but don't get any response.

{"id": 1, "method": "eth_subscribe", "params": ["newPendingTransactions"]}

Could you provide clearer procedures how you reproduce it?

[silvercondor]

@thomas-nguy it's not that we actually need the JSON-RPC txpool namespace. The eth_subscribe is not part of that txpool and already implemented in cronos. By subscribing to the "newPendingTransactions" we get a stream of hashes. What are these hashes? Why can't we query them using the standard eth_getTransactionByHash?
In tendermint there is this concept of "unconfirmed_txs", but I've tried querying them in cronos and they're always the same and never changing? (i.e. not getting "pending" transactions)

I couldn't reproduce it, I tried the follow request in websocket API, and sending some transactions to the chain, but don't get any response.

{"id": 1, "method": "eth_subscribe", "params": ["newPendingTransactions"]}

Could you provide clearer procedures how you reproduce it?

try restart your node, the socket probably dead due to #207

[yihuang]

try restart your node, the socket probably dead due to #207

thanks, reproduced now, will fix soon.

[yihuang]

will be fixed by this PR: evmos/ethermint#900
Do you want us to backport to current mainnet, or we just include it in next major release?

[Cryptome2]

will be fixed by this PR: tharsis/ethermint#900 Do you want us to backport to current mainnet, or we just include it in next major release?

can we use this already?

[yihuang]

will be fixed by this PR: tharsis/ethermint#900 Do you want us to backport to current mainnet, or we just include it in next major release?

can we use this already?

no, but we can backport it to 0.6.x branch, then it'll be usable immediately.

[Cryptome2]

would be great thanks

[xfwil]

will be fixed by this PR: tharsis/ethermint#900 Do you want us to backport to current mainnet, or we just include it in next major release?

can we use this already?

no, but we can backport it to 0.6.x branch, then it'll be usable immediately.

This applied on newest version? cronos newewst version is 0.6.5 but i still get nothing.

[yihuang]

will be fixed by this PR: tharsis/ethermint#900 Do you want us to backport to current mainnet, or we just include it in next major release?

can we use this already?

no, but we can backport it to 0.6.x branch, then it'll be usable immediately.

This applied on newest version? cronos newewst version is 0.6.5 but i still get nothing.

the fix is backported to release/v0.6.x branch, haven't released yet, but you can build a binary locally.

[yihuang]

the fix is included in recent release: https://github.com/crypto-org-chain/cronos/releases/tag/v0.6.6