Replace unreachable error handling with assertions in feebumper #12361

pull promag wants to merge 1 commits into bitcoin:master from promag:2018-02-feebumper changing 1 files +6 −14
  1. promag commented at 10:27 PM on February 5, 2018: member

    No description provided.

  2. fanquake added the label Wallet on Feb 5, 2018
  3. promag commented at 11:22 PM on February 5, 2018: member

    Ping @sdaftuar, author of this code.

  4. laanwj renamed this:
    Replace unreachable error handling with assertions in feebumber
    Replace unreachable error handling with assertions in feebumper
    on Feb 6, 2018
  5. promag force-pushed on Feb 6, 2018
  6. promag commented at 10:55 PM on February 6, 2018: member

    Fixed typo in commit message (feebumber -> feebumper). Thanks @laanwj.

  7. in src/wallet/feebumper.cpp:263 in 2d58539a1f outdated
     258 | @@ -265,11 +259,8 @@ Result CommitTransaction(CWallet* wallet, const uint256& txid, CMutableTransacti
     259 |      wtxBumped.fTimeReceivedIsTxTime = true;
     260 |      wtxBumped.fFromMe = true;
     261 |      CValidationState state;
     262 | -    if (!wallet->CommitTransaction(wtxBumped, reservekey, g_connman.get(), state)) {
     263 | -        // NOTE: CommitTransaction never returns false, so this should never happen.
     264 | -        errors.push_back(strprintf("The transaction was rejected: %s", state.GetRejectReason()));
     265 | -        return Result::WALLET_ERROR;
     266 | -    }
     267 | +    // NOTE: CommitTransaction never returns false.
    


    MarcoFalke commented at 11:09 PM on February 6, 2018:

    According to a comment, this is about to change:

    // TODO: if we expect the failure to be long term or permanent, instead delete wtx from the wallet and return failure.
    

    promag commented at 9:33 AM on February 8, 2018:

    ATM the comment is correct. The assertion below helps detecting if that changes.


    MarcoFalke commented at 8:19 PM on February 8, 2018:

    Even if we changed it to return false, it will do so very rarely. Likely never in tests. So whenever this changes we introduce a non-deterministic crash when calling an rpc and no one notices until it is out in the wild.

  8. [feebumper] Replace unreachable error handling with assertions 820a562568
  9. in src/wallet/feebumper.cpp:263 in 2d58539a1f outdated
     263 | -        // NOTE: CommitTransaction never returns false, so this should never happen.
     264 | -        errors.push_back(strprintf("The transaction was rejected: %s", state.GetRejectReason()));
     265 | -        return Result::WALLET_ERROR;
     266 | -    }
     267 | +    // NOTE: CommitTransaction never returns false.
     268 | +    assert(wallet->CommitTransaction(wtxBumped, reservekey, g_connman.get(), state));
    


    MarcoFalke commented at 11:09 PM on February 6, 2018:

    Could make sense to move it out of the assertion, such that the code continues to run if assertions are not compiled.


    promag commented at 9:38 AM on February 8, 2018:

    Agree, done.

  10. promag force-pushed on Feb 8, 2018
  11. in src/wallet/feebumper.cpp:262 in 820a562568
     258 | @@ -265,11 +259,9 @@ Result CommitTransaction(CWallet* wallet, const uint256& txid, CMutableTransacti
     259 |      wtxBumped.fTimeReceivedIsTxTime = true;
     260 |      wtxBumped.fFromMe = true;
     261 |      CValidationState state;
     262 | -    if (!wallet->CommitTransaction(wtxBumped, reservekey, g_connman.get(), state)) {
     263 | -        // NOTE: CommitTransaction never returns false, so this should never happen.
     264 | -        errors.push_back(strprintf("The transaction was rejected: %s", state.GetRejectReason()));
     265 | -        return Result::WALLET_ERROR;
     266 | -    }
     267 | +    bool result = wallet->CommitTransaction(wtxBumped, reservekey, g_connman.get(), state));
    


    sdaftuar commented at 7:34 PM on February 8, 2018:

    Rather than asserting that the result is true, I think it would make more sense to change the signature of CommitTransaction so that it doesn't return anything.


    promag commented at 12:42 AM on February 9, 2018:
  12. in src/wallet/feebumper.cpp:39 in 820a562568
      39 | -        // This should never happen, because IsAllFromMe(ISMINE_SPENDABLE)
      40 | -        // implies that we can sign for every input.
      41 | -        return -1;
      42 | -    }
      43 | +    // IsAllFromMe(ISMINE_SPENDABLE) implies that we can sign for every input.
      44 | +    assert(wallet->DummySignTx(txNew, vCoins));
    


    sdaftuar commented at 7:45 PM on February 8, 2018:

    While I think the comment here is correct, I don't think that adding an assert is very helpful to detecting if this were to change -- having the software crash on some user in the wild if somehow we violate this assumption in some edge case seems worse than recovering and producing an error message.


    promag commented at 12:50 AM on February 9, 2018:

    Side note, I should split in two lines as per @MarcoFalke suggestion.


    promag commented at 12:53 AM on February 9, 2018:

    Maybe we should remove the comment.

  13. sdaftuar commented at 7:48 PM on February 8, 2018: member

    I'm skeptical of adding assert's for unusual but otherwise benign situations -- I think our tests of this logic aren't complete enough to be sure that adding an assert would actually catch a newly-introduced bug in testing, before release.

    So we'd basically just be getting the downside of it potentially causing some user's node to crash when it otherwise could have produced an error message and continued.

    Perhaps we could just improve the error message, to indicate that the user should report the error to the software developers if it were to trigger?

  14. laanwj commented at 8:10 PM on February 8, 2018: member

    I'm skeptical of adding assert's for unusual but otherwise benign situations

    We should especially avoid that in network code, very easy to introduce a DoS vector.

  15. promag commented at 12:54 AM on February 9, 2018: member

    Perhaps we could just improve the error message, to indicate that the user should report the error to the software developers if it were to trigger?

    I have no strong opinion in this matter.

    I'm skeptical of adding assert's for unusual but otherwise benign situations

    Closing after @sdaftuar reasoning.

  16. promag closed this on Feb 9, 2018

  17. promag deleted the branch on Feb 9, 2018
  18. DrahtBot locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-21 15:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me