Page MenuHomePhabricator

[Cashtab] Do not show unacceptable offers to buyers, highlight them uniquely to sellers
ClosedPublic

Authored by bytesofman on Thu, Jan 2, 14:24.

Details

Summary

It is possible for agora offers to be "unacceptable", i.e. the terms of the offer are such that the min buy is smaller than the tokens available to buy.

Cashtab has a bug where validation is not correctly catching this, allowing such offers to be created. But even if (er, when) we catch it in Cashtab, anyone could make such an offer, so we need logic to handle them.

Test Plan

npm test, see screenshot. will patch the UI validation that is making these possible in a subsequent diff. For now this bug is helpful for testing this.

image.png (458×1 px, 55 KB)

Diff Detail

Repository
rABC Bitcoin ABC
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

confirm behavior with test

Modify behavior so that selectedOffer cannot be an unrendered offer

bytesofman published this revision for review.Thu, Jan 2, 14:57
Fabien requested changes to this revision.Thu, Jan 2, 15:10
Fabien added a subscriber: Fabien.
Fabien added inline comments.
cashtab/src/components/Agora/OrderBook/index.tsx
630 ↗(On Diff #51917)

You should not account for the non rendered quantities, otherwise you can end up with an order book with depth not reaching 100% which is weird (maybe check this in your unit test ?)

649 ↗(On Diff #51917)

See above, you should continue at the very beginning of the loop before any processing

This revision now requires changes to proceed.Thu, Jan 2, 15:10
bytesofman added inline comments.
cashtab/src/components/Agora/OrderBook/index.tsx
630 ↗(On Diff #51917)

in this case ... we probably "should" test it. It is (probably) possible to get the impact of this on the visual component by confirming expected width of the depth bars.

However

  • pretty complex mocks required just for this test
  • this value (now) is only used for rendering, which is imo easier to confirm by just glancing at any orderbook

once we start displaying this offer in a tooltip, then we will be testing for the actual value (not its derived impact on a css property), and this would be more straighforward to do and also provide a more valuable behavior confirmation. Since we are planning to do this imminently, I think it makes sense to wait.

bytesofman marked an inline comment as done.

continue before any analytic logic

It is (probably) possible to get the impact of this on the visual component by confirming expected width of the depth bars.

Why would you do that ? Just test that the value is not accounted in the depth computation. Anyway it's really a nit

This revision is now accepted and ready to land.Thu, Jan 2, 15:44