v11.12.0

• The protocol schema follows the nightly stand's pin, rippled develop at 0229c29 (Xrpl.BinaryCodec 11.12.0.0): the SmartEscrow fields GasLimit, BytecodeSizeLimit, GasPrice, Gas, GasUsed (UInt32 81-85), Bytecode (Blob 47) and VMReturnCode (Int32 3), and the results temINVALID_BYTECODE, temTEMP_DISABLED, tefNO_BYTECODE, tefBYTECODE_NOT_INCLUDED, tecOUT_OF_GAS and tecBYTECODE_REJECTED, taken from the node's server_definitions
• LedgerRules.FromNodeAsync sets LargeNumbers when MPTokensV2 is enabled, as rippled develop's setCurrentTransactionRules now selects the large Number mantissa for it
• TestULedgerRules checks the scale LedgerRules.FromFeatures gives for each amendment that selects the large mantissa, and without them
• Reliable submission reports what happened to a transaction, not when the SDK stopped looking (#266). SubmitAndWait and SubmitRequestAndWait:
  • decide expiry against the validated ledger instead of the open one
  • look the transaction up with min_ledger (the ledger validated before submission) and max_ledger (LastLedgerSequence), and report it expired only when the node's searched_all proves it in none of them, or, since rippled answers searched_all only for ranges where every ledger holds a transaction, when each ledger of the range, read validated with its transactions once LastLedgerSequence is validated, does not list it (up to 256 ledgers)
  • report a transaction that is in none of the range as unknown, not expired, when the submission answered tefPAST_SEQ, tefNO_TICKET or tefALREADY: the blob or its sequence was already used, possibly by an earlier submission applied before the range
  • give up as unknown when the server's validated ledger stays where it is for 60 polls
  • end the wait on a provisional result only for a tem. Without failHard a tec, ter, tef or tel is waited for, a tec reported once validated with its metadata. Under failHard any other result but tefALREADY, tefPAST_SEQ and tefNO_TICKET is looked up once and followed if found, and otherwise fails with ReachedLedger false. A blob submitted again after it was applied returns its success
• TransactionExpiredException: never applied, with Hash, LastLedgerSequence, MinLedger, PreliminaryResult and SearchedAll (proven by the lookup's own searched_all rather than by reading the ledgers)
• TransactionOutcomeUnknownException: possibly applied, with the same fields and the cause in InnerException. Raised when the submit request fails other than by an error answer from the node, or with internalSubmit or internalJson, when a lookup or a ledger read fails while waiting, and when the validated ledger is five past LastLedgerSequence while the node lacks part of the range
• TransactionWaitCanceledException, an OperationCanceledException with the caller's token, raised when the caller cancels after the submit request was sent; its Hash, LastLedgerSequence, MinLedger and PreliminaryResult resume the wait
• SubmitSugar.WaitForTransactionOutcome(hash, lastLedgerSequence, minLedger) waits for a transaction already submitted, without submitting it again; it accepts a minLedger past lastLedgerSequence, as an unknown outcome can carry
• ErrorResponse.SearchedAll
• TransactionFailedException(message, engineResult, hash, reachedLedger) states ReachedLedger where the code alone does not tell
• Breaking: an expired transaction raised ValidationException, the type that also means nothing was submitted; it now raises TransactionExpiredException. A failure while waiting raised ValidationException, RippledException or XrplException; it now raises TransactionOutcomeUnknownException. A disconnect, a timeout or a not-connected failure of the submit request, which propagated as it was, is now TransactionOutcomeUnknownException around it. A provisional tec, ter, tef or tel no longer fails at once without failHard: it fails, or expires, once LastLedgerSequence is validated. Migration: catch TransactionExpiredException where an expiry was caught as ValidationException; on TransactionOutcomeUnknownException, call WaitForTransactionOutcome with its Hash, LastLedgerSequence and MinLedger before submitting a replacement
• Behaviour change: GetLedgerIndex returns the validated ledger, as its documentation and xrpl.js's getLedgerIndex say; it returned the open one. Autofill's LastLedgerSequence becomes validated + 20, one ledger shorter
• TestUSubmitOutcome covers each provisional result with and without failHard, the expiry by searched_all and by the ledgers, a held transaction still cached past its last ledger, a ledger that lists the transaction before the lookup returns it, a ledger the server lacks, failures while waiting, and which submit failures left nothing on the network; TestIReliableSubmission expires a terPRE_SEQ payment, submits an applied blob again at once and ledgers later, and tracks a transaction already sent, on a node
• MainnetNode-Guide (both languages) says the expiry needs the node to hold the ledgers from submission to LastLedgerSequence