Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

The take screen reads the whole trade history to answer one order's rows

Open
  • Is something wrong?
#548 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
dart, flutter, rust, sqlite
Domain
database, mobile

Research direction

Start with tradeRoleLookupProvider, the storage trait in db/mod.rs, and the existing SQLite and IndexedDB implementations; trade_document_by_order_id is noted as a reference for the IndexedDB path. Check the expression index in schema.rs and the matching query in sqlite.rs, then trace the Rust API and regenerate its bindings. Done means the take check reads only that order's rows, still handles multiple rows and unreadable storage, and the contract and tests are updated.

Written by the indexing model from the issue text.

Description

area: rust-core priority: low

Summary

tradeRoleLookupProvider asks whether the user already takes part in an order by reading every trade row and filtering in Dart:

participatingRole(await readTrades(), orderId)

list_trades runs SELECT id, data FROM trades ORDER BY started_at DESC, serde_json-decodes every blob, and flutter_rust_bridge copies the whole Vec<TradeInfo> across — to keep, at most, the rows of one order. The take screen asks twice per take: once from initState (the participant redirect) and again on the Take tap, where the latency is felt.

The call it replaced, get_trade_role, went through the expression index instead:

SELECT data FROM trades WHERE json_extract(data, '$.order.id') = ? LIMIT 1

CREATE INDEX IF NOT EXISTS idx_trades_order_id
    ON trades(json_extract(data, '$.order.id'));

Raised by @grunch in review of #448, which moved the lookup to Dart because Rust had no "every row of this order" query. LIMIT 1 would not do: a database from before a confirmed take replaced its order's earlier rows can hold two, and a live one among them still makes the user a participant.

Context

This is not a new class of read — rawTradesProvider (My Trades), tradeInfoProvider and _followTradeRow's polling all read the full list. What is new is paying it on the take path, for an account whose history can hold hundreds of closed trades, each with bond and peer snapshots.

Proposal

Add a narrow bridge call, list_trades_for_order(order_id) -> Vec<TradeInfo>, over the existing index, and have tradeRoleLookupProvider read through it. participatingRole stays exactly as it is: a pure rule over the rows it is given, with its own unit tests.

Notes for whoever takes it:

  • The WHERE json_extract(data, '$.order.id') = ? expression must stay byte-identical to the others in sqlite.rs, or SQLite falls back to a full scan (see the comment above the index in schema.rs).
  • It is a new method on the storage trait (db/mod.rs), so it needs both implementations: SQLite and IndexedDB, where trade_document_by_order_id already shows the shape.
  • rust/src/api/ changes mean regenerated bindings committed in the same commit, and a line in specs/004-mostro-p2p-client/contracts/orders.md.
  • Keep the seam: the take screen's tests override the reader, not the role lookup, so the rule and its error handling stay under test.

Acceptance

  • The take screen's participant check no longer deserialises rows of other orders.
  • Two rows for the same order are still both read, so an open one wins over an ended take.
  • An unreadable store still answers "not a participant" rather than throwing (the contract get_trade_role had, restored in #448).

Related: #434, #448.

Dominant language
Dart
Stars
11
Forks
9
Avg merge
20h 31m
Merged PRs (30d)
231

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from MostroP2P/app

All issues in MostroP2P/app

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.