Release 11.5.1.0 - #188
Merged
Merged
Release 11.5.1.0#188
Conversation
…ls.Build validates (#187) * fix(validation)!: validators throw on the calling thread, so BatchUtils.Build validates Validation.Validate and the 86 validators behind it were declared async Task without ever awaiting anything, and BatchUtils.Build called Validate without awaiting the result. An async method captures every exception into the task it returns, including the ones thrown before the first await, so a discarded task is a discarded verdict: ValidateBatch ran, decided the batch was malformed and reported it to nobody. A Batch built around a single inner transaction - which rippled answers with temARRAY_EMPTY - came back from Build looking well formed, and so did one with more than eight inners, with a Vault/Loan inner, with an inner missing tfInnerBatchTxn, or with an inner carrying a non-zero Fee. The compiler had been saying so as CS4014 since the method was written. The validators now return void and throw on the calling thread. Conditions, exception types and messages are unchanged; `await Validation.Validate(tx)` no longer compiles - drop the await. Making the signature honest is the fix rather than adding the missing await: Build is synchronous and public, so awaiting would have meant Task<Batch> BuildAsync, and .GetAwaiter().GetResult() would have left the next caller the same trap. TestUCredentialsValidator wrapped the already-synchronous ValidateCredentialsList in Task.Run to fit the async assertion helper's Func<Task>. That worked while the helper awaited the task, and is exactly the shape that stops working once the assertion is synchronous, since Action accepts a lambda whose value is discarded. The nine tests call the validator directly now. Released as 11.5.1.0 rather than a major: the validators are opt-in, nothing inside the SDK calls them, and BatchUtils.Build - the one caller that did - is what this release fixes. CHANGES.md states the deviation for anyone calling Validation.* or Common.ValidateBaseTransaction directly. * docs(batch): say what ValidateBatch enforces, on the validator this release fixes
Platonenkov
enabled auto-merge
September 15, 2026 19:49
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Promotes
devtorelease. One commit since 11.5.0.0.What ships
fix(validation)!: validators throw on the calling thread, so BatchUtils.Build validates(b73762a, #187)BatchUtils.BuildcalledValidation.Validate(...)without awaiting it, andValidation.Validatewas declaredasync Task. Anasyncmethod captures every exception into the task it returns — including the ones thrown before the firstawait— so the discarded task discarded the verdict.ValidateBatchran, decided the batch was malformed, and reported it to nobody.A Batch built around a single inner transaction, which rippled answers with
temARRAY_EMPTY, came back fromBuildlooking well formed. So did one with more than eight inners, with aVault/Loaninner, with an inner missingtfInnerBatchTxn, or with an inner carrying a non-zeroFee— every rule inValidateBatchwas lost, not just the inner count. The compiler had been reporting it as CS4014 since the method was written.The 86 validators now return
voidand throw on the calling thread. Conditions, exception types and messages are unchanged.Packages
XrplXrpl.AddressCodecXrpl.BinaryCodecXrpl.Keypairsgit diff origin/release...origin/dev -- Base/is empty, so the three base packages keep their published versions andXrplcontinues to depend on them as they are.Read this before merging
This is a breaking change released as a patch, deliberately. Semver would call it a major: the return type is part of a method's signature in IL, so an assembly built against 11.5.0.0 meets a
MissingMethodExceptionon 11.5.1.0 even where it never wroteawait, and its sources need theawaitdropped before they compile again.It is numbered a patch because the validators are opt-in — nothing inside the SDK calls them, and
BatchUtils.Build, the one caller that did, is the method this release fixes.CHANGES.mdstates the deviation and tells anyone callingValidation.*orCommon.ValidateBaseTransactiondirectly to treat the upgrade as a major one: rebuild, and drop theawait.Merging this publishes to NuGet.org and GitHub Packages, and republishes the docs.
Verification
docker-compose.ci.ymlstand: 346 passed, 0 failed — run locally, and again by the merge queue against the merge result before fix(validation)!: validators throw on the calling thread, so BatchUtils.Build validates #187 landed ondevTests/Xrpl.Tests/Models/TestUBatchUtils.cspins the behaviour: a single inner refused, more than eight refused, a well-formed batch built