-
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
APIv2(AccountTx): Added error messages on AccountTx #4571
Conversation
src/test/rpc/AccountTx_test.cpp
Outdated
RPC::apiMaximumSupportedVersion == 1 | ||
? BEAST_EXPECT( | ||
hasTxs(env.rpc("json", "account_tx", to_string(p)))) | ||
: BEAST_EXPECT(isErr( | ||
env.rpc("json", "account_tx", to_string(p)), | ||
rpcLGR_IDX_MALFORMED)); |
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.
You should copy these tests for an explicit api_version == 1
, like this.
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.
To follow on @thejohnfreeman's suggestion, loop over both versions for these tests, because we need to keep supporting version 1 indefinitely and ensure it's working correctly.
src/ripple/rpc/impl/RPCHelpers.h
Outdated
constexpr unsigned int apiMaximumSupportedVersion = 1; | ||
constexpr unsigned int apiMaximumSupportedVersion = 2; | ||
constexpr unsigned int apiBetaVersion = 2; |
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.
Don't change the apiMaximumSupportedVersion
until the updated version is locked in and final and ready for release. We have apiBetaVersion
variable right here and the [beta_rpc_api]
config option available to allow testing the changes. (It might not be a bad idea to enable BETA_RPC_API = true
by default in envconfig.cpp.)
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.
Just wondering what do you mean by "until the updated version is locked in and final and ready for release."? Do you you mean until PR #4522 is merged into develop, so I don't have to change apiMaximumSupportedVersion to 2?
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'll be popping over to add the same kind of comment to #4568 and #4552 after I'm done here.
"until the updated version is locked in and final and ready for release" means that once a version of rippled
is released with apiMaximumSupportedVersion
is set to 2, then we are saying that API v2 is Done. Once that happens we can not legitimately make any further changes to API version 2. To the best of my knowledge, API version 2 is still in beta, under active development, and still changing.
Now, if you (and #4568 and #4552) are saying that version 2 is done, let's talk about version 2 being done. This will be the first I've heard about it.
If you want a node to properly handle API v2 requests, the correct way to do that, for now, is with the [beta_rpc_api]
config option. And if you want to do it in unit tests, set it up in the config similar to how it's done in https://github.com/XRPLF/rippled/blob/develop/src/test/rpc/AccountInfo_test.cpp#L209-L212, or just by setting cfg.BETA_RPC_API=true;
directly.
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.
Please see also #4573.
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.
Just to close the loop on this: API v2 will be considered "Done" in the 1.12 release. Any breaking changes in 1.13 will be API v3.
src/test/rpc/AccountTx_test.cpp
Outdated
RPC::apiMaximumSupportedVersion == 1 | ||
? BEAST_EXPECT( | ||
hasTxs(env.rpc("json", "account_tx", to_string(p)))) | ||
: BEAST_EXPECT(isErr( | ||
env.rpc("json", "account_tx", to_string(p)), | ||
rpcLGR_IDX_MALFORMED)); |
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.
To follow on @thejohnfreeman's suggestion, loop over both versions for these tests, because we need to keep supporting version 1 indefinitely and ensure it's working correctly.
src/test/rpc/AccountTx_test.cpp
Outdated
void | ||
testParametersApiV2() |
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.
Might wanna:
- Add a parameter for api_version.
- Call this method in a loop over versions from apiMinimumSupportedVersion to apiBetaVersion.
- Remove the other method.
- Make the assertion on the error value conditional on the api_version parameter, using condition < 2 for the old behavior and else for the new behavior.
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.
{ | ||
Json::Value response; | ||
// if ledger_index_min or max is specified, then ledger_hash or ledger_index | ||
// should not be specified. Error out if it is | ||
if (context.apiVersion > 1) |
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.
not so important, but I'm wondering if it'll be nice to make constants like API_VERSION_1 and API_VERSION_2 instead of using raw numbers 1 and 2 since we are using it in a lot of places ?
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 don't think it's worth it when we're just using consecutive integers to name the versions.
@@ -108,7 +108,7 @@ class AccountTx_test : public beast::unit_test::suite | |||
}; | |||
|
|||
void | |||
testParameters() | |||
testParameters(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.
Not related to this PR, but wondering why the test cases in this file do not have testcase(testCaseDesctiption)
?
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.
My guess is that we don't have any written, enforced guidelines for 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 think it might be useful to add testcase(testCaseDescription + v<apiVersion>)
so that users can see if the unit test is actually running on different versions when they run it. what do you think ? (maybe out of scope for this PR ?)
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 think our test framework and tests are long overdue for a redesign with firm and written guidelines, but I won't worry about the inconsistency in this PR.
Certain inputs for the AccountTx method should return an error. In other words, an invalid request from a user or client now results in an error message. Since this can change the response from the API, it is an API breaking change. This commit maintains backward compatibility by keeping the existing behavior for existing requests. When clients specify "api_version": 2, they will be able to get the updated error messages. Update unit tests to check the error based on the API version. * Fix XRPLF#4288 * Fix XRPLF#4545
Certain inputs for the AccountTx method should return an error. In other words, an invalid request from a user or client now results in an error message. Since this can change the response from the API, it is an API breaking change. This commit maintains backward compatibility by keeping the existing behavior for existing requests. When clients specify "api_version": 2, they will be able to get the updated error messages. Update unit tests to check the error based on the API version. * Fix XRPLF#4288 * Fix XRPLF#4545
Certain inputs for the AccountTx method should return an error. In other words, an invalid request from a user or client now results in an error message. Since this can change the response from the API, it is an API breaking change. This commit maintains backward compatibility by keeping the existing behavior for existing requests. When clients specify "api_version": 2, they will be able to get the updated error messages. Update unit tests to check the error based on the API version. * Fix XRPLF#4288 * Fix XRPLF#4545
High Level Overview of Change
Fixed error messages for AccountTx method for Github Issue #4545 and #4288
Context of Change
Certain input for AccountTx method should of error'ed out
Type of Change
Invalid request by user results in Error message
Before and After: refer to github link. Using "api_version": 2 calls the updated error messages
Updated existing unit test to check error based off of VPI versioning as adding error messages is considered a breaking c hange.