Skip to content

Bug (Mempool): Tx from Genesis key diseapear in the Aptos core mempool. #1185

Closed

Description

@musitdev

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

Activity

  1. added
    bugIndicates that the issue is a bug or a software defect.
    on Apr 8, 2025
  2. added theissue type on Apr 8, 2025
  3. linked a pull request that will close this issuefix: restore unit tests #1187on Apr 8, 2025
  4. ganymedio commented on Apr 8, 2025

    @ganymedio
    Contributor

    @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).

    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:

    1. 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?

    2. 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?

  5. ganymedio commented on Apr 9, 2025

    @ganymedio
    Contributor

    Closing as the tests have been fixed in the merge of #1186

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    aptos-corebugIndicates that the issue is a bug or a software defect.

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions