support for eth_pendingTransactions

[mohoff]

Hi, it seems that the call eth_pendingTransactions is currently not supported, while getting a pending block is supported via block(BlockNumber::Pending.into) as #404 claims. A stackoverflow answer suggests that eth_pendingTransactions is Geth specific and thus maybe the reason why it isn't supported here?

If mistaken, I can give the implementation a try with some hints.

[tomusdrw]

hey! Happy to accept the PR, the library was originally based on Parity's/OpenEthereum's RPCs, but tries not to be biased towards any particular client (if it's within the RPC spec).

[mohoff]

Thanks @tomusdrw . I researched a bit more and found that getting pending transactions is not part of the standard JSON RPC API but can be found under different names in client-specific calls:

• geth: txpool_content. Already supported in api/tx_pool.rs.
• parity/openethereum: parity_pendingtransactions. Currently not supported although several other parity_* calls do exist in this crate.

What is confusing for me is that web3.js supports a eth_pendingTransactions call but implements none of the official client-specific calls listed above. What do I fail to understand here?

Assuming my digging is correct, we can just add support for parity_pendingTransactions and call it a day. This would enable users to fetch pending transactions for both clients. Additionally, does a client-agnostic eth().get_pending_transactions() make sense for you as part of this crate?

[tomusdrw]

What is confusing for me is that web3.js supports a eth_pendingTransactions call but implements none of the official client-specific calls listed above. What do I fail to understand here?

Might be some historical reasons, or for instance compatibility with Ganache?

Assuming my digging is correct, we can just add support for parity_pendingTransactions and call it a day. This would enable users to fetch pending transactions for both clients.

Yes, I like the idea.

Additionally, does a client-agnostic eth().get_pending_transactions() make sense for you as part of this crate?

If you mean to support Ganache for instance - sure, but please make sure that's the case and we need to document it properly. If you mean to have a call that will attempt to unify Geth and OpenEthereum behaviour - then no, I'd like to keep the APIs as close to the spec and low-level RPCs as possible. We could introduce some more high-level "compat" namespace for this if needed.

[mohoff]

Implemented by #451