Skip to content

[Wave 6 6/10] Frontend order recovery from coordinator API after reload #29

Description

@karagozemin

Summary

Add frontend order recovery from the coordinator API so pending/refundable swaps survive page reloads instead of relying only on local UI state.

Context

  • The frontend has refund UI and transaction history components, but recovery across reloads depends on what the browser still knows.
  • The coordinator persists order state and is the right source for reconstructing pending/refundable swaps.
  • This improves the core safety promise: users can return later and still see how to claim or refund.

Scope

  • Add a small frontend service/hook to fetch orders for the connected Ethereum/Stellar addresses from the coordinator.
  • Merge recovered orders into TransactionHistory without duplicating locally created orders.
  • Surface refundable status into RefundDialog when the recovered order has enough on-chain metadata.
  • Add tests for reload/recovery and duplicate suppression.

Acceptance criteria

  • After reconnecting a wallet, the frontend requests relevant coordinator orders and renders them in transaction history.
  • Recovered orders with expired timelocks expose the refund action when the contract/order id is known.
  • Local pending orders and recovered orders are de-duplicated by hashlock/order id/tx hash.
  • Frontend tests cover successful recovery and coordinator failure fallback.

Pointers

  • frontend/src/components/TransactionHistory.tsx
  • frontend/src/features/refund/RefundDialog.tsx
  • frontend/src/lib/sdk-context.ts
  • frontend/src/lib/useNetworkMode.ts
  • coordinator/src/server/routes/orders.ts
  • packages/sdk/src/types/index.ts

Complexity

Medium (frontend state + API integration)

Metadata

Metadata

Assignees

Labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions