test: cover feebumper enormous-cluster failure #35021

1. 
   LucasVarella commented at 8:40 am on April 7, 2026: none

   Summary

   When a wallet transaction’s unconfirmed inputs reference an aggregate mempool ancestor set whose size exceeds the GatherClusters() DoS limit (currently 500), MiniMiner cannot compute combined bump fees and CreateRateBumpTransaction() must surface a clear error to the caller instead of crashing or silently returning garbage.

   This adds a unit test that constructs the offending topology, eight disjoint mempool chains, each at the cluster-count cap, totalling 512 transactions, and exercises CreateRateBumpTransaction through a wallet tx whose inputs are the chain tips. The test asserts the expected Result::WALLET_ERROR and that the surfaced error mentions the cluster-of-unconfirmed-transactions condition.

   The construction is parameterised on MAX_CLUSTER_COUNT_LIMIT and the local kGatherClustersDoSLimit, so it survives changes to either; a static_assert pins the relationship at compile time. A second static_assert ensures the cluster count fits in the coinbases provided by TestChain100Setup.

   Test plan

   • cmake --build build --target test_bitcoin --config Release -j
   • build/bin/Release/test_bitcoin.exe --run_test=feebumper_tests --log_level=message passes
   • Mutation check: temporarily change if (ret.size() > 500) in src/txmempool.cpp:988 to > 1000, rebuild, confirm the test now fails with both assertions, then revert

   Related

   Closes #34902.

2. test: cover feebumper enormous-cluster failure

   When a wallet transaction's unconfirmed inputs reference an
   aggregate mempool ancestor set whose size exceeds the
   GatherClusters() DoS limit (currently 500), MiniMiner cannot
   compute combined bump fees and CreateRateBumpTransaction() must
   surface a clear error to the caller instead of crashing or
   silently returning garbage.
   
   This adds a unit test that constructs the offending topology
   (eight disjoint mempool chains, each at the cluster-count cap,
   totalling 512 transactions) and exercises CreateRateBumpTransaction
   through a wallet tx whose inputs are the chain tips. The test
   asserts the expected Result::WALLET_ERROR and that the surfaced
   error mentions the cluster-of-unconfirmed-transactions condition.
   
   The construction is parameterised on MAX_CLUSTER_COUNT_LIMIT and
   the local kGatherClustersDoSLimit, so it survives changes to either;
   a static_assert pins the relationship at compile time. A second
   static_assert ensures the cluster count fits in the coinbases
   provided by TestChain100Setup.

   9af0bef6f7
3. DrahtBot added the label Tests on Apr 7, 2026
4. 
   DrahtBot commented at 8:40 am on April 7, 2026: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

   Conflicts

   Reviewers, this pull request conflicts with the following ones:

   • #34924 (test: add feebumper coverage for combined bump fee failure by MkDev11)

   If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

   LLM Linter (✨ experimental)

   Possible places where named args for integral literals may be used (e.g. func(x, /*named_arg=*/0) in C++, and func(x, named_arg=0) in Python):

   • CreateRateBumpTransaction(*wallet, original_txid, coin_control, errors, old_fee, new_fee, bumped_tx, /*require_mine=*/true, /*outputs=*/{}, /*original_change_index=*/std::nullopt) in src/wallet/test/feebumper_tests.cpp

   2026-04-07 08:40:35

5. maflcko closed this on Apr 7, 2026

   ---

6. 
   maflcko commented at 9:12 am on April 7, 2026: member

   pls do not create duplicates
7. 
   LucasVarella commented at 2:09 pm on April 7, 2026: none

   @maflcko what do you mean by duplicate?
8. 
   maflcko commented at 6:04 pm on April 7, 2026: member

   You can read the prior comment: #35021 (comment), which lists the conflict/duplicate
9. 
   LucasVarella commented at 6:25 pm on April 7, 2026: none

   @maflcko sure, but this is a branch that hasn’t been merged into main yet, and the conflict is with a solution submitted by another contributor. Even though my PR may seem like a duplicate, it has significant differences.

   Since this is my first time contributing, I’d really like to learn and better understand how this works. Is priority always given to the contributor who submits first?

10. 
    maflcko commented at 6:33 pm on April 7, 2026: member

    it has significant differences.

    The burden is on the pull request author to explain the differences and why they are preferable. Generally, it is better to leave your preferences as a review comment on the existing pull request. Only if the approaches are orthogonal or otherwise incompatible, it makes sense to open a separate pull.

11. 
    LucasVarella commented at 6:38 pm on April 7, 2026: none

    Got it, @maflcko! Thank you so much for taking the time to reply.

Contributors
LucasVarella DrahtBot maflcko

Labels
Tests