Tx failed error - #1526

What

This adds TransactionFailedError, a new error type raised by Horizon.Server.submitTransaction and submitAsyncTransaction when Horizon rejects a transaction, and fixes the submission error path so SDK error types are actually thrown.

TransactionFailedError extends BadResponseError and adds two accessors, mirroring the ergonomics of the Go SDK's horizonclient.Error:

• getResultCodes() — returns the { transaction, operations } result codes directly, e.g. { transaction: "tx_failed", operations: ["op_underfunded"] }. Horizon omits operations for transaction-level failures like tx_bad_seq (verified against a live network), so the accessor normalizes it to [] and guarantees an array.
• getTransactionResult() — decodes extras.result_xdr into an xdr.TransactionResult, giving structured access to per-operation results without touching base64 (or null if Horizon sent no result_xdr).

Alongside that:

• Both submit methods now route rejections through a shared toSubmissionError() helper: responses carrying Horizon result codes become TransactionFailedError, any other HTTP error (rate limit, server error, the async endpoint's distinct 400 payload) becomes BadResponseError, and genuine network errors (DNS, timeout, socket) still pass through untouched. The original HTTP client error is preserved as err.cause, so response.headers, config, and axios-specific fields remain reachable.
• The same dead-branch pattern existed in Federation.Server._sendRequest: resolveAddress, resolveAccountId, resolveTransactionId, and forDomain now also reject HTTP failures with BadResponseError (original error as cause), with the maxContentLength size-limit behavior unchanged.
• HorizonApi.TransactionFailedResultCodes gained the transaction result codes it was missing: tx_bad_sponsorship, tx_bad_min_seq_age_or_gap, tx_malformed, tx_soroban_invalid, and tx_frozen_key_accessed.
• result_codes.operations stays typed as required for backwards compatibility even though Horizon can omit it; making it optional is a source-breaking type change deferred to the next major (Make TransactionFailedExtras result_codes.operations optional (breaking type fix) #1527).

Why

Fixes #413 — a request from 2020 for a simple way to get error codes out of a failed submission, instead of digging through err.response.data.extras.result_codes.

Fixes #1437 — the root cause that made this worse than the original ask: the documented behavior of rejecting with BadResponseError never actually happened. The catch handlers' instanceof Error check passed raw HTTP client errors straight through, since they are Error instances — the wrapping branch was unreachable, in both the Horizon submit methods and the Federation resolution methods. So consumers have been coding against an undocumented rejection shape with no SDK type to narrow on, no accessors, and no XDR decoding.

Note for reviewers: this is observable-behavior-changing even though no TypeScript API breaks. err.response.data and err.response.status are unchanged, but the error message text differs and HTTP-client-specific fields moved to err.cause. The changelog spells out the migration details. Verified end-to-end against a local quickstart network across four scenarios: op-level failure (op_underfunded), tx-level failure (tx_bad_seq), the async endpoint, and a successful submission.

🤖 Generated with Claude Code