-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Conversation
I think that makes sense. I'm not sure how useful that information is because only local transactions are queued on the light client. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
ethcore/src/miner/miner.rs
Outdated
} | ||
|
||
result |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe wrap the result in Ok
here, this way we don't need the if
above.
Yes, it notifies about all transactions that are inserted to the queue (and transactions from retracted blocks are re-inserted). |
hi guys, wonderful to have this. just to clarify:
did i get it right? geth docs seem to suggest that only local pendings would go out through this subscription |
@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. |
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 |
@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. |
thanks for the clarification, i imagined there must be some kind of limitations |
Resolves #6426
@rphmeier what's your thoughts on light client? Should we notify about every transaction in light queue?