You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug (Mempool): Tx from Genesis key diseapear in the Aptos core mempool. #1185
Describe the bug
A clear and concise description of what the bug is.
The test 'transactionPipe::test_pipe_mempool_one_tx' fails because the Aptos CoreMempool accepts created Tx using the genesis account but doesn't produce any batch with them. They seem to diseapears in the mempool.
Current these Tx are the only that can be tested because the genesis account is the only one that is funded.
Is it related to this account, to the ledger that is used by the mempool that isn't correctly inited, ...
The issue resolution will allow making all Tx test in the full node and executor to pass.
To Reproduce
To reproduce execute the test 'transactionPipe::test_pipe_mempool_one_tx'
DOT_MOVEMENT_PATH="$(pwd)/.movement" cargo test -p maptos-opt-executor test_pipe_mempool_one_tx
@musitdev@mzabaluev I got test_pipe_mempool_one_tx to pass and opened a draft PR against /musitdev/update-fullnode-client-call branch from #1186 (which is where that test originated).
I set the sequence number to 0 and it passed. The assertions in the test appear to be valid. (It only passes by itself right now; when you run the other tests with it it seems maybe they clobber each other and it fails.)
My questions are:
Do you see this as a legit fix? I don't understand why setting the sequence number to 0 makes the test pass, just want to be sure it actually makes sense. Why do you think it passes with sequence number set to 0?
I'm a bit confused about how we should handle fixing the tests. The tests on main differ a bit from the tests in the feature branch and Mikhail's branch mikhail/executor-test-fixes as well as from musitdev/update-fullnode-client-call. So maybe a good approach would be since we've identified one that can be fixed in the feature branch, we focus on fixing as many as we can in the feature branch first?
Activity
ganymedio commentedon Apr 8, 2025
@musitdev @mzabaluev I got
test_pipe_mempool_one_txto pass and opened a draft PR against/musitdev/update-fullnode-client-callbranch from #1186 (which is where that test originated).Here's the draft PR I made to demonstrate: #1188
I set the sequence number to 0 and it passed. The assertions in the test appear to be valid. (It only passes by itself right now; when you run the other tests with it it seems maybe they clobber each other and it fails.)
My questions are:
Do you see this as a legit fix? I don't understand why setting the sequence number to 0 makes the test pass, just want to be sure it actually makes sense. Why do you think it passes with sequence number set to 0?
I'm a bit confused about how we should handle fixing the tests. The tests on
maindiffer a bit from the tests in the feature branch and Mikhail's branchmikhail/executor-test-fixesas well as frommusitdev/update-fullnode-client-call. So maybe a good approach would be since we've identified one that can be fixed in the feature branch, we focus on fixing as many as we can in the feature branch first?ganymedio commentedon Apr 9, 2025
Closing as the tests have been fixed in the merge of #1186