No description provided.
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-
promag commented at 10:27 PM on February 5, 2018: member
- fanquake added the label Wallet on Feb 5, 2018
- laanwj renamed this:
Replace unreachable error handling with assertions in feebumber
Replace unreachable error handling with assertions in feebumper
on Feb 6, 2018 - promag force-pushed on Feb 6, 2018
-
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.
[feebumper] Replace unreachable error handling with assertions 820a562568in 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.
promag force-pushed on Feb 8, 2018in 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:See #12361 (review).
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.
sdaftuar commented at 7:48 PM on February 8, 2018: memberI'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?
laanwj commented at 8:10 PM on February 8, 2018: memberI'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.
promag commented at 12:54 AM on February 9, 2018: memberPerhaps 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.
promag closed this on Feb 9, 2018promag deleted the branch on Feb 9, 2018DrahtBot locked this on Sep 8, 2021ContributorsLabels
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