Merge injectable-definitions - #44
Merged
Merged
Conversation
The 2.0.0 entry stated that the lock file had been stale since the buffer bump and that a fresh `composer install` therefore failed. composer.lock is gitignored in this repository, so no consumer and no fresh clone ever saw that lock - it was an artifact of one local working copy, and `composer require hardcastle/xrpl_php` resolves from composer.json as usual. What does stand is the reason for the guzzle bump: the constraint `^7.4` allowed 7.4.0 through 7.15.1, all of which carry open advisories, so anyone resolving the tree could land on a vulnerable version. The Security entry is reworded accordingly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Definitions::fromArray() and Definitions::fromFile() build a set from outside; the constructor takes the decoded definitions and validates that all five sections are present - BinaryCodec, BinaryParser, Wallet, JsonRpcClient, HashLedger::hashSignedTx(), Sugar\getLastLedgerSequence() and Sugar\isAccountDelete() take an optional Definitions instance - BinaryParser carries the definitions through the decode; StObject and StArray keep them on the parsed instance so toJson() uses the same set - StObject::fromJson() and StArray::fromJson() take an optional Definitions and pass it into nested objects and arrays - Wallet::sign() hashes through the wallet's own definitions instead of the default ones - The Sugar functions build their codec from the client's definitions - README: section "Using your own definitions" - 11 tests in InjectableDefinitionsTest All parameters are optional and default to the bundled XRP Ledger definitions.
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
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.
Summary
Prepares the ground for a separate Xahau package by letting the codec work against definitions handed in from outside.
2.0.0 documented that Xahau support is broken for 23 transaction types but could not fix it: the two networks assign different ordinals to the types they share, so a single merged definitions set is wrong for one side no matter which
way the merge resolves.
MPTokenIssuanceCreateis 54 on the XRP Ledger and 63 on Xahau; of the 59 shared types only 36 line up.This PR does not fix Xahau — it makes fixing it possible from outside:
Verified against the live Xahau node's own server_definitions: the same transaction encodes to ordinal 54 with the bundled definitions and 63 with Xahau's, and both signatures verify.
Why not a Network enum
Because it would put a second network's concept into the public API of a library that is otherwise entirely about the XRP Ledger — Wallet::fromSeed() would grow a network parameter that most callers never touch. Handing in a Definitions instance keeps the seam internal and works for any network, not just Xahau. When the Xahau types eventually leave this library, nothing in the API has to change back.
Scope
Smaller than it first looked. Only two serialized types resolve field names, so only those two needed a parameter:
BinaryParser carries the definitions through the decode, so fromParser() needed no signature change anywhere. StObject and StArray keep them on the parsed instance so that toJson() resolves names against the same set.
No breaking changes. Every new parameter is optional and falls back to the bundled XRP Ledger definitions.
Fixed along the way
Tests
11 new tests in InjectableDefinitionsTest, covering encode, decode, nested objects, wallet signing, hashing, and that an injected set does not leak into the shared default instance.
The alternative definitions are built by remapping ordinals in the bundled set rather than checking in a second large fixture — that reproduces exactly what makes the networks incompatible, without a network dependency in the suite.
One note on test quality: the first version of the hashing test compared two hashes over the string path, where the hash is definitions-independent by construction. It would have passed without the fix. It is replaced by one that uses a field only the injected definitions know, and I verified it fails at Wallet.php:152 → HashLedger.php:50 when the fix is reverted.
550 tests green.
Not covered