Skip to content

fix(exchange): stop one unparseable order from wiping the order list - #2531

Draft
BullishNode wants to merge 1 commit into
mainfrom
fix/tolerant-order-parsing
Draft

fix(exchange): stop one unparseable order from wiping the order list#2531
BullishNode wants to merge 1 commit into
mainfrom
fix/tolerant-order-parsing

Conversation

@BullishNode

Copy link
Copy Markdown
Contributor

⚠️ Requires emulator/device review before merge — draft until verified on a real account. Test: log into an account whose history contains an Expired-status order (the reporter's account is the fixture) and confirm the transactions list shows all exchange transactions (Pay, Reward, etc.), rewards show real amounts instead of 0 sats.

Problem

The API legitimately sends order values the app refused to parse: status Expired (distinct from Payment deadline expired), payout status Failed, order type Sell USDT, empty payin/payout statuses, and null exchange-rate/deadline fields on admin-initiated orders. Both batch parse layers (datasource listOrderSummaries and repository getOrders) turned the first such order into an empty list, hiding every exchange transaction in the app. Confirmed in device logs: Error fetching orders — Exception: Unknown OrderStatus: Expired. Server contract verified against API-Orders orderSummary.ts.

Changes

  • Parse per element with skip-and-log at both layers, and in getOrderByTxId
  • Unknown-tolerant fromValue on OrderStatus/OrderPayinStatus/OrderPayoutStatus/OrderType; add missing members (Expired, Failed, Sell USDT)
  • Unknown order types render generically via a new Order.generic variant carrying the server-sent type name
  • exchangeRateAmount/exchangeRateCurrency/confirmationDeadline now nullable (matching the server), with guards at consumers
  • Reward amounts read from the payout side (payin is empty for admin-initiated orders → rendered 0 sats)
  • Fiat-vs-sats display derived from the order instead of a hardcoded variant list (fixes fiat refunds shown as sats, BTC balance adjustments formatted as fiat)

Validation

15 new regression tests (poisoned-list survival at both layers, each new enum value, null fields, reward amount); flutter analyze clean; reviewed with a verification pass (2 should-fixes applied). Note: this branch touches Countdown null-guards in buy/pay/sell screens — minor line-disjoint overlap with the sibling fix PRs at merge.

Closes #2526
Closes #2527

The API legitimately sends order values the app refused to parse:
status 'Expired' (distinct from 'Payment deadline expired'), payout
status 'Failed', order type 'Sell USDT', empty payin/payout statuses,
and null exchange rate and confirmation deadline fields on
admin-initiated orders. Both batch parse layers turned the first such
order into an empty list, hiding every exchange transaction in the app.

- Parse per element with skip-and-log at both layers (datasource
  listOrderSummaries and repository getOrders), and in getOrderByTxId.
- Make OrderStatus, OrderPayinStatus, OrderPayoutStatus and OrderType
  tolerant of unknown values; add the known missing members.
- Render unknown order types generically via a new Order.generic
  variant carrying the server-sent type name.
- Relax exchangeRateAmount, exchangeRateCurrency and
  confirmationDeadline to nullable, matching the server contract, with
  null guards at their consumers.
- Read reward amounts from the payout side; the payin side is empty
  for admin-initiated orders and rendered every reward as 0 sats.
- Derive fiat-vs-sats display from the order instead of a hardcoded
  variant list, fixing fiat refunds shown as sats and BTC balance
  adjustments formatted as fiat.

Closes #2526
Closes #2527
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