[Tests] Add prioritisetransaction RPC test#7063
Conversation
There was a problem hiding this comment.
Nit: Shouldn't the print appear in front of assert? So when it fails, we know where it did (Not just by line number)?
There was a problem hiding this comment.
Well then it would be printing something incorrect if the assertion failed. I guess I could add a different print statement above the asserts, but not sure it's worth it? If the assertion fails I think the stack trace is informative enough, and I don't think the style here is inconsistent with the rest of the tests.
There was a problem hiding this comment.
Where would you put a comment, when you had put one? Then just replace the # with print and you get in L109:
print "Assert that prioritised transaction was mined"
There was a problem hiding this comment.
rest of the tests
I see no reason to do this. You could as well just remove the print completely.
|
utACK |
4c6b6f3 to
596e839
Compare
|
Rebased, moved prints |
|
Merged via 6abf6eb (needed trivial rebase change in rpc-tests.py) |
|
utACK 6abf6eb |
|
PR can be closed!? |
@morcos mentioned in #6898 (comment) that there's no rpc test for
prioritisetransaction. This adds a simple test to exercise this logic.In writing this test I discovered something unusual -- if you try to set a fee delta using
prioritisetransactionthat is negative and greater in magnitude than the transaction's fee, you get incorrect results. TheCFeeRateconstructor that takes a fee and size doesn't work if you pass in a negative fee. I don't really understand the details of how conversion and type promotion work in this kind of situation, but as far as I can tell, on my machine, I think the compiler promotes theint64_t nFeePaidto auint64_t(nSizeis asize_t):Link to the code:
bitcoin/src/amount.cpp
Line 15 in c983d6f
I think this arithmetic may work on a 32-bit platform, because it looked to me like doing arithmetic with an
unsigned intrather than asize_tappeared to work.Anyway I expect that #6898 will fix
prioritisetransactionto work properly with fee deltas that bring the modified fee below 0, so I just avoided that issue for now in this test; I can update it in the future to include that case after #6898.