Skip to content
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

Merged
merged 8 commits into from
Jun 29, 2023
Merged

APIv2(AccountTx): Added error messages on AccountTx #4571

merged 8 commits into from
Jun 29, 2023

Conversation

PeterChen13579
Copy link
Contributor

@PeterChen13579 PeterChen13579 commented Jun 13, 2023

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

  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Tests (You added tests for code that already exists, or your new feature included in this PR)

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.

@PeterChen13579 PeterChen13579 changed the title Changed error messages on AccountTx Added error messages on AccountTx Jun 13, 2023
Comment on lines 169 to 174
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));
Copy link
Collaborator

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.

Copy link
Collaborator

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.

Comment on lines 244 to 245
constexpr unsigned int apiMaximumSupportedVersion = 1;
constexpr unsigned int apiMaximumSupportedVersion = 2;
constexpr unsigned int apiBetaVersion = 2;
Copy link
Collaborator

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.)

Copy link
Contributor Author

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?

Copy link
Collaborator

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:/XRPLF/rippled/blob/develop/src/test/rpc/AccountInfo_test.cpp#L209-L212, or just by setting cfg.BETA_RPC_API=true; directly.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see also #4573.

Copy link
Collaborator

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.

Comment on lines 169 to 174
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));
Copy link
Collaborator

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.

@intelliot intelliot added this to the 1.12 milestone Jun 20, 2023
@intelliot intelliot added the Passed Passed code review & PR owner thinks it's ready to merge. Perf sign-off may still be required. label Jun 21, 2023
src/test/rpc/AccountTx_test.cpp Outdated Show resolved Hide resolved
@intelliot intelliot removed the Passed Passed code review & PR owner thinks it's ready to merge. Perf sign-off may still be required. label Jun 23, 2023
Comment on lines 251 to 252
void
testParametersApiV2()
Copy link
Collaborator

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.

Copy link
Collaborator

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)
Copy link
Collaborator

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 ?

Copy link
Collaborator

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)
Copy link
Collaborator

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) ?

Copy link
Collaborator

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.

Copy link
Collaborator

@arihantkothari arihantkothari Jun 28, 2023

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 ?)

Copy link
Collaborator

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.

@intelliot intelliot merged commit d34e8be into XRPLF:develop Jun 29, 2023
ckeshava pushed a commit to ckeshava/rippled that referenced this pull request Jul 10, 2023
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
@intelliot intelliot mentioned this pull request Jul 18, 2023
1 task
@intelliot intelliot changed the title Added error messages on AccountTx APIv2(AccountTx): Added error messages on AccountTx Aug 1, 2023
ckeshava pushed a commit to ckeshava/rippled that referenced this pull request Sep 22, 2023
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
ckeshava pushed a commit to ckeshava/rippled that referenced this pull request Sep 25, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

5 participants