-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix EscrowFinish fulfillment and condition parsing #512
Conversation
…ent to the raw value when re-written before setting typed fields.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #512 +/- ##
============================================
+ Coverage 92.00% 92.01% +0.01%
- Complexity 1833 1835 +2
============================================
Files 381 381
Lines 5090 5098 +8
Branches 431 433 +2
============================================
+ Hits 4683 4691 +8
Misses 272 272
Partials 135 135
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
…crow-fulfillments
…/xrpl4j into nk/fix-escrow-fulfillments
Fixes #513
As seen in transaction
138543329687544CDAFCD3AB0DCBFE9C4F8E710397747BA7155F19426F493C8D
, sometimesEscrowFinish
transactions can show up in validated ledger transaction sets with an invalid fulfillment or condition. We added afulfillmentRawValue
andconditionRawValue
, and normalization functions to try to makefulfillment()
equivalent tofulfillmentRawValue
andcondition()
equivalent toconditionRawValue
in #483. However, we missed a special case where the fulfillment or condition could be well formed in the first 32 bytes, but contain extra bytes afterward (in the case of 138543329687544CDAFCD3AB0DCBFE9C4F8E710397747BA7155F19426F493C8D, the fulfillment is duplicated), which causes an exception to be thrown by the normalization function.This PR fixes this issue by checking that the parsed fulfillment or condition is equivalent to the fulfillment/condition raw value. If it is not equivalent, we will not set
fulfillment
orcondition
. If it is, we will.