Pending transactions subscription

[tomusdrw]

Resolves #6426

@rphmeier what's your thoughts on light client? Should we notify about every transaction in light queue?

[rphmeier]

I think that makes sense. I'm not sure how useful that information is because only local transactions are queued on the light client.

[andresilva]

LGTM. Not sure if you're going to change the light client behavior.

From geth documentation (https://github.com/ethereum/go-ethereum/wiki/RPC-PUB-SUB#newpendingtransactions):

When a transaction that was previously part of the canonical chain isn't part of the new canonical chain after a reogranization its again emitted.

Do/should we have the same behavior?

[andresilva]

Maybe wrap the result in Ok here, this way we don't need the if above.

[tomusdrw]

Do/should we have the same behavior?

Yes, it notifies about all transactions that are inserted to the queue (and transactions from retracted blocks are re-inserted).

[tzapu]

hi guys, wonderful to have this.

just to clarify:

• in light mode only local transactions are in the pool and sent through the subscription
• in full mode everything added to the pending pool is sent through

did i get it right?
Cheers

geth docs seem to suggest that only local pendings would go out through this subscription
this would make it work wildly different than the pending transactions filter though...

[tomusdrw]

@tzapu Correct. Yes, I saw a suggestion in geth docs, although checked the code and they seem to push every transaction to the subscription (which IMHO makes sense, TBH we should also inform about transactions that are dropped/replaced in the pool - I will prepare a parity-specific method for that in the future). Let me know if the behaviour is undesirable, we can change it.

[tzapu]

well, ideally, my use case would benefit from feature parity between modes, so light mode also gets the entirety of pending transactions, but i get that that might be undesirable, unwarranted or maybe not even possible

other than that, this is perfect. also, the dropped/replaced subscription or call would be absolutely wonderful

thanks again for all your hard work

[rphmeier]

@tzapu the behavior on light clients is because light clients don't even accept or re-propagate transactions from the rest of the network. even the basic validity checks of "does this sender have enough of a balance to pay the fee" and "is this transaction valid in the future or valid now?" are quite expensive for light clients to handle.

[tzapu]

thanks for the clarification, i imagined there must be some kind of limitations
love the progress on everything 👍 🎉 🎈