Skip to content

rpc: testmempoolaccept reports txn-already-in-mempool for confirmed transactions #628

Description

@Hero-Gamer

Summary

The Core functional mempool_accept.py test currently exposes a reject-reason mismatch in testmempoolaccept.

For a transaction that has already been mined into the chain, Bitcoin Core v31 reports:

{"reject-reason": "txn-already-known"}

rbitcoin currently reports:

{"reject-reason": "txn-already-in-mempool"}

In the observed run, getmempoolinfo also reports size=0, so this does not appear to be a case of the transaction actually remaining in the mempool.

Reproduction

This is exposed by the Core functional mempool_accept.py test after the maxfeerate prerequisite is fixed:

  1. Mine one block.
  2. Take the raw transaction from that block.
  3. Call testmempoolaccept with that raw transaction.

The relevant test is mempool_accept.py around line 125 in the pinned Core v31.1 functional-test inventory.

Current result:

txn-already-in-mempool

Expected Core result:

txn-already-known

PR #626 fixed the preceding maxfeerate failure that previously prevented this assertion from being reached, but deliberately leaves the inventory entry skipped so this separate compatibility issue can be addressed independently.

Expected behavior

For a transaction already confirmed in the active chain, testmempoolaccept should return the Core-compatible txn-already-known reject reason rather than txn-already-in-mempool.

The likely issue is the order/source of the existing-known transaction check versus the mempool check. The exact implementation point should be confirmed during the fix rather than assuming a particular refactor.

Scope

This is an RPC/Core functional compatibility issue, not a consensus-rule change. The goal is narrowly to make the confirmed-transaction case report the same reject reason as Bitcoin Core.


I will open a follow-up PR to fix this and add a focused regression test.

I do not intend to broaden that PR into making the entire mempool_accept.py inventory entry pass if unrelated compatibility failures are uncovered afterward.

No activity

Activity on this issue will appear here.

Activity

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

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions