test: switch order of error code and message check #34366

I feel it'd be easier to debug intermittent test failures if the error message is present in the logs instead of error code. So, switching order of error code and message in the try_rpc function to aid error debugging.

Should help in debugging #34354 IMO. It's an intermittent failure on Windows that I can't reproduce and it's more difficult to figure out what could have gone wrong only by seeing the error code like below in the CI logs. Given that the functional tests pass, I don't see a harm in checking for error message first and throwing it in case of a mismatch.

AssertionError: Unexpected JSONRPC error code -1

<!-- *** Please remove the following help text before submitting: *** Pull requests without a rationale and clear improvement may be closed immediately. GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->

<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. -->

<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. -->

<!--e57a25ab6845829454e8d69fc972939a-->

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

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34366.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

lgtm ACK 0aba464ce76522f1be3bb9e471b45438738de492

lgtm ACK 0aba464ce76522f1be3bb9e471b45438738de492

utACK 0aba464ce76522f1be3bb9e471b45438738de492

Great idea!

code review ACK 0aba464ce76522f1be3bb9e471b45438738de492

Should help in debugging #34354 IMO. It's an intermittent failure on Windows that I can't reproduce and it's more difficult to figure out what could have gone wrong only by seeing the error code like below in the CI logs.

I don't think this help here, because python will already print the full exception while handling another one. It prints in the logs: test_framework.authproxy.JSONRPCException: filesystem error: cannot remove: The process cannot access the file because it is being used by another process [D:\a\_temp\test_runner_₿_🏃_20260120_132914\wallet_assumeutxo_56\node3\regtest\w2\wallet.dat] (-1)

Though, i still think it makes sense to merge this, because the message is more human friendly than the code, and probably more unique and meaningful. So it probably doesn't help for the quoted issue, but in other contexts.

ACK 0aba464ce76522f1be3bb9e471b45438738de492

I don't think this help here, because python will already print the full exception while handling another one.

Thanks for pointing out, you are correct. Usually, I have noticed this python exception handling behaviour in my local, but I missed it in the logs of this issue. By default, the last line in the stack trace catches my attention immediately and seeing an error message there will be helpful, might even save some time while debugging. But, yeah, the overall benefit of this PR is mostly cosmetic.