Three bug fixes targeting credential handling in RPCSub resubscription, a race condition in TransactionEntry's ledger hash resolution for API v2, and malformed error return types in multi-sign field validation are now identified with precise contribution paths in rippled.

> impact

**What changed.** Three discrete issues in rippled's RPC layer have been surfaced and scoped for contribution. First, the `subscribe` handler's reuse branch silently ignores the current `url_username`/`url_password` field names when updating credentials on an existing `RPCSub` object, falling back only to the deprecated `username`/`password` fields. Second, the `TransactionEntry` handler's API v2 code path redundantly calls `getHashBySeq()` after `lookupLedger` has already resolved the ledger, introducing a race window where a cache miss overwrites a valid `ledger_hash` with a zero `uint256`. Third, `checkMultiSignFields` in `TransactionSign.cpp` returns a raw `std::string` from `invalid_field_message()` instead of a JSON error object, causing the downstream `contains_error()` guard to miss the failure entirely. **Why it matters.** The credential bug means any client using the non-deprecated field names (`url_username`/`url_password`) to rotate subscription credentials will silently fail to update them, risking stale authentication or outright 401s from callback targets. The zero-hash race condition can deliver an all-zeros `ledger_hash` in otherwise successful `transaction_entry` responses, which breaks any downstream logic that relies on the hash for verification, caching, or indexing. The malformed error return in multi-sign validation lets structurally invalid requests (where `tx_json` is present but not a JSON object) slip past input guards, potentially causing deeper, harder-to-diagnose failures later in the signing pipeline. **Impact for builders.** If you maintain infrastructure that rotates RPC subscription credentials, resubscribes via `url_username`/`url_password`, queries `transaction_entry` on API v2, or submits multi-signed transactions programmatically, these fixes directly affect your reliability surface. All three are tightly scoped, single-file changes suitable for a first contribution to rippled.

> Try this now

try this

# ── Fix 1: RPCSub credential update on resubscribe ──────────────────────
# File: src/xrpld/rpc/handlers/subscribe/Subscribe.cpp
# Lines 36-49 already correctly resolve credentials from either field name:
#   strUsername = context.params[jss::url_username] || context.params[jss::username]
#   strPassword = context.params[jss::url_password] || context.params[jss::password]
#
# Problem: Lines 73-88 (the reuse branch) only check the deprecated fields:
#   if (context.params.isMember(jss::username))  // <-- misses url_username
#       rpcSub->setUsername(...);
#
# Fix: Replace the conditional checks with unconditional calls using the
# already-resolved variables. The values default to empty strings if absent,
# so this is safe:
#   rpcSub->setUsername(strUsername);   // always set, already resolved above
#   rpcSub->setPassword(strPassword);   // always set, already resolved above
# This mirrors the resolution logic and removes the deprecated-field-only gate.

# ── Fix 2: TransactionEntry zero-hash race condition (API v2) ───────────
# File: src/xrpld/rpc/handlers/transaction/TransactionEntry.cpp
# Lines ~61-65, inside the `if (!lpLedger->open())` block for v2:
#
#   // BEFORE (racy):
#   uint256 uLedgerHash = context.ledgerMaster.getHashBySeq(lpLedger->seq());
#   jvResult[jss::ledger_hash] = to_string(uLedgerHash);
#
#   // AFTER (deterministic – use the ledger object we already hold):
#   jvResult[jss::ledger_hash] = to_string(lpLedger->info().hash);
#
# getHashBySeq hits a cache that can miss under load; the ledger object
# itself always carries its own hash. One-line replacement, no new deps.

# ── Fix 3: checkMultiSignFields returns string instead of error JSON ────
# File: src/xrpld/rpc/handlers/TransactionSign.cpp
# Line ~1032:
#
#   // BEFORE (returns bare string, invisible to contains_error()):
#   if (!request.isMember(jss::tx_json) || !request[jss::tx_json].isObject())
#       return RPC::invalid_field_message(jss::tx_json);
#
#   // AFTER (returns proper JSON error object):
#   if (!request.isMember(jss::tx_json) || !request[jss::tx_json].isObject())
#       return RPC::make_error(
#           rpcINVALID_PARAMS,
#           RPC::invalid_field_message(jss::tx_json));
#
# Audit nearby helpers (checkSingleSign, transactionSignFor) for the same
# pattern with invalid_field_message / missing_field_message.
#
# Add a test in src/test/rpc/:
#   // Submit sign_for with tx_json set to a string instead of an object
#   auto const result = env.rpc("sign_for", ..., "tx_json", "not_an_object");
#   BEAST_EXPECT(result.isMember(jss::error));
#   BEAST_EXPECT(result[jss::error] == "invalidParams");