-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat/lw 11842 performance improvements #1530
base: master
Are you sure you want to change the base?
Conversation
|
Added more unit tests for rollback behaviour here: 6d0e216 |
This change is needed to fix tests because transactions tracker is relying on accurate block range fetches from chain history provider.
@@ -152,13 +152,15 @@ const findIntersectionAndUpdateTxStore = ({ | |||
lowerBound !== undefined && `since block ${lowerBound}` | |||
); | |||
|
|||
const txRolledBack = lastStoredTransaction && newTransactions[0]?.id !== lastStoredTransaction.id; | |||
const txRolledBack = | |||
lastStoredTransaction && newTransactions[newTransactions.length - 1]?.id !== lastStoredTransaction.id; |
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.
I think this should be looking only at the first block from newTransactions
- lastStoredTransaction && newTransactions[newTransactions.length - 1]?.id !== lastStoredTransaction.id;
+ const newTxFirstBlock = newTransactions.filter(tx => tx.blockHeader.blockNo === lowerBound);
+ lastStoredTransaction && newTxFirstBlock[newTxFirstBlock.length - 1]?.id !== lastStoredTransaction.id;
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.
I am rewriting this logic here, sec
@@ -280,6 +280,42 @@ describe('TransactionsTracker', () => { | |||
pagination: { limit: 25, startAt: 0 } | |||
}); | |||
}); | |||
|
|||
describe('distinct transaction sets in latest stored block vs new blocks', () => { |
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.
@mkazlauskas , @AngelCastilloB , please review these proposed scenarios to cover in unit tests.
If they make sense and improve coverage I will implement them.
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.
Looks good 💪 , just don't quite understand when/how this could happen reversed order transactions plus new tx are re-emitted, but not considered rollbacks
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.
It is far fetched, but I was thinking of a scenario where a competing SP has txId 3 in the mempool, then gets a mempool update with txId 2, then another with txId 1, and creates a fork with the 3 transactions <3 2 1>.
I'm not sure if that is even possible tbh 😅
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.
Looks great @mirceahasegan , I think we just need to add the case where there are no changes somewhere:
// latestStoredBlock <1 2 3>
// fetched Txs <1 2 3>
Or is it that this is already covered by the already existing tests?
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.
Thanksk @mirceahasegan , better safe than sorry 😅
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.
I would say it's already covered in the other tests, for single transaction blocks.
I'll add one for the multi-transaction block scenario too, just to be safe.
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.
Unit tests are implemented in ef247ea.
The commit also contains a fix for an issue discovered in tx tracker.
There still are ~3 tests that are failing and we need to investigate if they're bugs or test issues after updating implementation
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.
all tests are green now
Context
TBD
Proposed Solution
TBD
Important Changes Introduced
TBD