-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix unit test api_version to enable api_version 2 #4785
Conversation
src/test/rpc/RPCCall_test.cpp
Outdated
@@ -6403,7 +6403,7 @@ std::string | |||
updateAPIVersionString(const char* const req) | |||
{ | |||
static std::string version_str = | |||
std::to_string(RPC::apiMaximumSupportedVersion); | |||
std::to_string(RPC::apiMinimumSupportedVersion); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should minimum
version be default or apiVersionIfUnspecified
? Both of them = 1 right now, so it doesn't really matter. But I am just curious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know most of the times (maybe all the times), apiVersionIfUnspecified = apiMinimumSupportedVersion
will be true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cannot say no. I.e., probably make sense to use apiVersionIfUnspecified
as default.
src/test/rpc/RPCCall_test.cpp
Outdated
@@ -6403,7 +6403,7 @@ std::string | |||
updateAPIVersionString(const char* const req) | |||
{ | |||
static std::string version_str = | |||
std::to_string(RPC::apiMaximumSupportedVersion); | |||
std::to_string(RPC::apiMinimumSupportedVersion); | |||
static auto place_holder = "%MAX_API_VER%"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are putting minimum version as version_str
. Should this line instead be static auto place_holder = "%MIN_API_VER%";
? [line 6407]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it back to RPC::apiMaximumSupportedVersion
and we will see what we eventually decide to use as default. Could be apiVersionIfUnspecified
as you said earlier.
src/ripple/net/impl/RPCCall.cpp
Outdated
@@ -1561,7 +1563,8 @@ rpcClient( | |||
try | |||
{ | |||
Json::Value jvRpc = Json::Value(Json::objectValue); | |||
jvRequest = rpcCmdLineToJson(args, jvRpc, logs.journal("RPCParser")); | |||
auto apiVersion = fromCmdLine? RPC::apiMaximumSupportedVersion : RPC::apiMinimumSupportedVersion; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather not have this logic hardcoded in this location; it would be easier to understand if rpcClient
took explicitly unsigned apiVersion
parameter instead, and then fromCommandLine
passes RPC::apiMaximumSupportedVersion
. That maintains isolation of concerns and also enables unit tests to test different versions (by which, I mean more than two) of command line generated parameters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, if you go this way, I would add assert(apiVersion <= RPC::apiBetaVersion);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, changed.
src/ripple/net/impl/RPCCall.cpp
Outdated
@@ -1698,7 +1701,7 @@ fromCommandLine( | |||
const std::vector<std::string>& vCmd, | |||
Logs& logs) | |||
{ | |||
auto const result = rpcClient(vCmd, config, logs); | |||
auto const result = rpcClient(vCmd, config, logs, true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as mentioned above, instead of true
pass RPC::apiMaximumSupportedVersion
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
IMHO, this solution is backwards. When a new API version becomes officially supported, we want incompatible unit tests to break. That is a signal that they are version dependent and need to be updated to test all API versions (preferably), or a least updated to the latest API version. |
Agree. Exposing |
There's a helper function, |
I kind of agree with what @ximinez said about "this solution is backwards". That could be the reason we had I addressed @Bronek comments. Now the apiVersion is unit tests' choice, instead of having to use what the command line use. A bigger discussion is what should be used as unit test default. What @arihantkothari said ( |
@pwang200 - from your perspective, is this PR ready for review + merge? |
Now we can start using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, that's an overall improvement.
|
||
/** Internal invocation of RPC client. | ||
* Used by both rippled command line as well as rippled unit tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this comment ! 👍
@@ -1698,7 +1672,8 @@ fromCommandLine( | |||
const std::vector<std::string>& vCmd, | |||
Logs& logs) | |||
{ | |||
auto const result = rpcClient(vCmd, config, logs); | |||
auto const result = | |||
rpcClient(vCmd, config, logs, RPC::apiMaximumSupportedVersion); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, this means that as soon as we bump apiMaximumSupportedVersion
, the tx_history
and ledger_header
commands will stop working (as they are no longer recognized in API version 2). Ideally at this point we should remove them from parseCommand
in this file (and also remove function RPCParser::parseTxHistory
). This probably needs its own issue.
yes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 This looks good. Approving as-is, but left two nits to consider. (I'm fine if the nits are not addressed).
src/ripple/net/RPCCall.h
Outdated
rpcCmdToJson( | ||
std::vector<std::string> const& args, | ||
Json::Value& retParams, | ||
beast::Journal j, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually we make journal
the last parameter.
src/ripple/net/RPCCall.h
Outdated
std::vector<std::string> const& args, | ||
Json::Value& retParams, | ||
beast::Journal j, | ||
unsigned int apiVersion); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe not for this PR, but we should consider making apiVersion either an enum type with one enum per API version or maybe a strongly-typed int (int with a tag, like we do with base_uint).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm 👍
re-requested review since a new commit was pushed after the last review. Also, should we try to merge #4775 prior to this one? |
There's no need to delay this PR |
The command line API still uses `apiMaximumSupportedVersion`. The unit test RPCs use `apiMinimumSupportedVersion` if unspecified. Context: - XRPLF#4568 - XRPLF#4552
This PR attempts to address the unit test api_version issues discussed in a previous PR #4568
apiMaximumSupportedVersion
.apiMinimumSupportedVersion
if unspecified.