Validator operators are often flummoxed by the below error:
It would be helpful if the error message can instruct the users to run the rippled server in another process (./rippled) before executing any of the command-line client commands.
Context of Change
Type of Change
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Refactor (non-breaking change that only restructures code)
[ ] Performance (increase or change in throughput and/or latency)
[ ] Tests (you added tests for code that already exists, or your new feature included in this PR)
[x] Documentation update
[ ] Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
[ ] Release
This is an elaboration of an error message.
API Impact
[ ] Public API: New feature (new methods and/or new fields)
[ ] Public API: Breaking change (in general, breaking changes should only impact the next api_version)
[ ] libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
[ ] Peer protocol change (must be backward compatible or bump the peer protocol version)
No change to API. No impact on performance either.
I manually verified (on MacOS) that the new error message is displayed, if rippled server isn't running in the background.
High Level Overview of Change
Validator operators are often flummoxed by the below error:
It would be helpful if the error message can instruct the users to run the rippled server in another process (
./rippled
) before executing any of the command-line client commands.Context of Change
Type of Change
.gitignore
, formatting, dropping support for older tooling)This is an elaboration of an error message.
API Impact
libxrpl
change (any change that may affectlibxrpl
or dependents oflibxrpl
)I manually verified (on MacOS) that the new error message is displayed, if rippled server isn't running in the background.