Skip to content

fix maximum amt#34

Merged
gregtatcam merged 3 commits intogregtatcam:feature/mpt-v1from
shawnxie999:fix-exceed-max-amt
Sep 10, 2024
Merged

fix maximum amt#34
gregtatcam merged 3 commits intogregtatcam:feature/mpt-v1from
shawnxie999:fix-exceed-max-amt

Conversation

@shawnxie999
Copy link
Copy Markdown

High Level Overview of Change

Context of Change

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Refactor (non-breaking change that only restructures code)
  • Performance (increase or change in throughput and/or latency)
  • Tests (you added tests for code that already exists, or your new feature included in this PR)
  • Documentation update
  • Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
  • Release

API Impact

  • Public API: New feature (new methods and/or new fields)
  • Public API: Breaking change (in general, breaking changes should only impact the next api_version)
  • libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
  • Peer protocol change (must be backward compatible or bump the peer protocol version)


if (sle->getFieldU64(sfOutstandingAmount) + saAmount.value() >
(*sle)[~sfMaximumAmount].value_or(maxMPTokenAmount))
return tecMPT_MAX_AMOUNT_EXCEEDED;
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should add a unit-test for this.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we already have existing unit tests that tests if the issuer issues out more than the max. the unit test i added covered the scenario reproduced in QA that currently exhibits the wrong behavior

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this a different execution path?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the existing test cases hit this new if-check in rippleSend. The problem found is that during holder to holder payment, rippleCredit is called twice from 1) holder to issuer and then 2)issuer to holder. The current problem is that in the second rippleCredit call from issuer to holder, the code think the issuer is trying to issue more than the MaximumAmount. This is why I moved the check in the rippleCredit to its caller rippleSend.

@gregtatcam gregtatcam merged commit 6364440 into gregtatcam:feature/mpt-v1 Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants