Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 12 additions & 6 deletions transaction-pool/src/pool.rs
Original file line number Diff line number Diff line change
Expand Up @@ -611,20 +611,26 @@ impl<'a, T, R, S, L> Iterator for PendingIterator<'a, T, R, S, L> where
self.best_transactions.take(&best).expect("Just taken from iterator; qed")
};

match self.ready.is_ready(&best.transaction) {
Readiness::Ready => {
// retrieve next one from that sender.
let tx_state = self.ready.is_ready(&best.transaction);
// Add the next best sender's transaction when applicable
match tx_state {
Readiness::Ready | Readiness::Stale => {
// retrieve next one from the same sender.
let next = self.pool.transactions
.get(best.transaction.sender())
.and_then(|s| s.find_next(&best.transaction, &self.pool.scoring));
if let Some((score, tx)) = next {
self.best_transactions.insert(ScoreWithRef::new(score, tx));
}
Comment thread
ngotchac marked this conversation as resolved.

return Some(best.transaction.transaction)
},
state => trace!("[{:?}] Ignoring {:?} transaction.", best.transaction.hash(), state),
_ => (),
}

if tx_state == Readiness::Ready {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've actually meant to put the if inside previous match and leave the trace in _ pattern, but this is fine as well.

Just got an idea that for readability we could also change both this if and match above to if let, but it's up to you.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought it would be clearer to have one match when we need to find the next transactions, and another one when we need to return the transaction, but I'm open to anything :)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My reasoning was that it's easier to see everything that happens in particular case(ses) in a single block, cause now you fall-through and need to analyze multiple blocks to think about what happens. But as I said, I'm not strong on this either.

return Some(best.transaction.transaction)
}

trace!("[{:?}] Ignoring {:?} transaction.", best.transaction.hash(), tx_state);
}

None
Expand Down
17 changes: 17 additions & 0 deletions transaction-pool/src/tests/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -267,6 +267,23 @@ fn should_construct_pending() {
assert_eq!(pending.next(), None);
}

#[test]
fn should_skip_staled_pending_transactions() {
let b = TransactionBuilder::default();
let mut txq = TestPool::default();

let tx0 = import(&mut txq, b.tx().nonce(0).gas_price(5).new()).unwrap();
let tx2 = import(&mut txq, b.tx().nonce(2).gas_price(5).new()).unwrap();
let tx1 = import(&mut txq, b.tx().nonce(1).gas_price(5).new()).unwrap();

// tx0 and tx1 are Stale, tx2 is Ready
let mut pending = txq.pending(NonceReady::new(2));

// tx0 and tx1 should be skipped, tx2 should be the next Ready
assert_eq!(pending.next(), Some(tx2));
assert_eq!(pending.next(), None);
}

#[test]
fn should_return_unordered_iterator() {
// given
Expand Down