fix: account_tx limit parameter validation for malformed values

[Copilot]

High Level Overview of Change

Fixed account_tx RPC method to properly validate malformed limit parameter values. Previously, invalid values like 0, 1.2, "10", true, false, -1, [], {}, etc. were either accepted without errors or caused internal errors. Now all malformed values correctly return invalidParams error.

Fixes #5138

Context of Change

This is a bug fix for improper parameter validation in the account_tx RPC method. The bug has existed since the method was implemented - the original code directly called asUInt() on the limit parameter without proper type validation, which bypassed type checking and caused implicit conversions or internal errors.

The fix follows the established pattern used by other RPC methods (like account_lines) by:

1. Adding proper type validation to reject non-integer values
2. Explicitly rejecting invalid values like 0
3. Using the existing readLimitField helper function for consistent behavior

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• Tests (you added tests for code that already exists, or your new feature included in this PR)

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)

Before / After

Before (incorrect behavior):

Request with limit = 0:

{"method": "account_tx", "params": [{"account": "rpU4XtUSB7vx7hnDbkJ7pdbqAHEEoxTL33", "limit": 0}]}

Response: Success with transactions (incorrect - should reject invalid limit)

Request with limit = "10":

{"method": "account_tx", "params": [{"account": "rpU4XtUSB7vx7hnDbkJ7pdbqAHEEoxTL33", "limit": "10"}]}

Response: Success (incorrect - should reject non-integer)

Request with limit = -1:

{"method": "account_tx", "params": [{"account": "rpU4XtUSB7vx7hnDbkJ7pdbqAHEEoxTL33", "limit": -1}]}

Response: Internal error (incorrect error type)

After (correct behavior):

Request with limit = 0:

{"method": "account_tx", "params": [{"account": "rpU4XtUSB7vx7hnDbkJ7pdbqAHEEoxTL33", "limit": 0}]}

Response:

{
    "result": {
        "error": "invalidParams",
        "error_code": 31,
        "error_message": "Invalid parameters.",
        "status": "error"
    }
}

Request with limit = "10", 1.2, true, false, -1, [], {}, etc.:

{"method": "account_tx", "params": [{"account": "rpU4XtUSB7vx7hnDbkJ7pdbqAHEEoxTL33", "limit": "10"}]}

Response:

{
    "result": {
        "error": "invalidParams",
        "error_code": 31,
        "error_message": "Invalid field 'limit', not unsigned integer.",
        "status": "error"
    }
}

Valid request with limit = 10:

{"method": "account_tx", "params": [{"account": "rpU4XtUSB7vx7hnDbkJ7pdbqAHEEoxTL33", "limit": 10}]}

Response: Success with up to 10 transactions

Test Plan

Added comprehensive test coverage in AccountTx_test.cpp for all malformed limit values from the issue:

• limit = 0 → returns rpcINVALID_PARAMS
• limit = 1.2, "10", true, false, -1, [], {}, "malformed", ["limit"], {"limit": 10} → return expected_field_error with message "Invalid field 'limit', not unsigned integer."
• limit = 10 (valid) → works correctly

The tests verify that:

1. Type validation correctly rejects non-integer types
2. Value validation correctly rejects 0
3. Valid integer values are accepted and processed correctly

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.5%. Comparing base (5e33ca5) to head (ce4d641).

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #5891     +/-   ##
=========================================
- Coverage     79.5%   79.5%   -0.0%     
=========================================
  Files          817     817             
  Lines        72210   72210             
  Branches      8280    8278      -2     
=========================================
- Hits         57398   57387     -11     
- Misses       14812   14823     +11     

Files with missing lines	Coverage Δ
src/xrpld/rpc/detail/RPCHelpers.cpp	82.8% <100.0%> (+0.2%)	⬆️
src/xrpld/rpc/detail/Tuning.h	100.0% <ø> (ø)
src/xrpld/rpc/handlers/AccountChannels.cpp	82.0% <ø> (-0.4%)	⬇️
src/xrpld/rpc/handlers/AccountLines.cpp	88.7% <ø> (+0.6%)	⬆️
src/xrpld/rpc/handlers/AccountOffers.cpp	89.7% <ø> (-0.3%)	⬇️
src/xrpld/rpc/handlers/AccountTx.cpp	88.0% <100.0%> (+0.1%)	⬆️

... and 5 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[godexsoft]

Overall this is fine. I believe in Clio we have the same behaviour.

[godexsoft]

nit: Why not directly use args.limit?

[mvadari]

Fair point - fixed

[godexsoft]

nit: err can be const

[mvadari]

Good catch - fixed

[bthomee]

Suggested change

	if (args.limit == 0)
	return rpcError(rpcINVALID_PARAMS);
	auto const& jvLimit = params[jss::limit];
	if (jvLimit.asUInt() == 0)
	return rpcError(rpcINVALID_PARAMS);

This should work, since the RPC::readLimitField will set args.limit to the minimum value of the accountTx's LimitRange. You wouldn't need to check that it's a uint anymore, since the readLimitField already has done so.

[mvadari]

I was thinking about adding it directly into readLimitField, but unsure if that'll break something in a separate RPC.

[bthomee]

Give it a shot, I'd say - assuming test coverage is sufficient.

[mvadari]

ce4d641

[bthomee]

Since this does change the error response for at least one RPC method, I'd like @godexsoft to take a second look.