Fixes #32264
I looked into all current failures listed in the issue, as well all tests that are already disabled for the cli with self.supports_cli = False
. There are several reasons why existing tests fail with --usecli
on many systems, the most important ones are:
- Most common reason is that the test executes a RPC call with a large arg that exceeds
MAX_ARG_STRLEN
of the OS, which is usually 128kb on linux: This is fixed by using-stdin
for these large calls (idea by 0xB10C) - they test specifically the rpc interface - nothing to do there except disabling.
- Some functional test submit wrong types to params on purpose to test the error message (which is different when using the cli) - deactivated these specific subtests locally for the cli when there is just one or two of them, deactivated the entire tests when there are more spots
- When python sets
None
for an arg, the cli converts this to ’null’ inarg_to_cli
. This is fine e.g. for boolean args, but doesn’t work for strings where it’s interpreted as the string ’null’. Bypass this for named args by not including args in case the value isNone
for the cli is used (it’s effectively the same as leaving the optional arg out). - the
height_or_hash
param used in some RPC needs to be converted to a JSON (effectively adding full quotes). - Some tests were marked with
self.supports_cli = False
in the past but run fine on master today - enabled those.
In total, this PR fixes all tests that fail on master and reduces the number of tests that are deactivated (self.supports_cli = False
) from 40 to 21.
It also adds --usecli
to one CI job (multiprocess, i686, DEBUG) to detect regressions.