Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

restore does not persist recovered orders, so recovered trades cannot be continued

Aperta
  • Qualcosa non va?
#188 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
rust, sql
Ambito
cli, databases

Direzione di ricerca

Start in the RestoreSession branch of src/parser/dms.rs, which prints restore_orders and restore_disputes without saving them, and read the context passed through src/cli/restore.rs. Check the orders schema in src/db.rs and how Order::get_by_id and User::get_trade_keys are used. Done means a restored order can be resolved by release or fiatsent without manual steps, and restore no longer claims success when nothing was persisted.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

mostro-cli restore asks Mostro for the user's active orders and disputes and prints them, but it never writes them into the local orders table. Every command that acts on a specific order looks it up there first, so after a mnemonic-only recovery the user can see their in-flight trades but cannot act on any of them.

This makes the documented "restore on a new machine" path incomplete: it recovers your identity, but not your ability to finish a trade that was already open.

Found while auditing the README against the code (#186), which now documents the limitation. This issue tracks closing the gap in the code.

Reproduction

On a machine whose ~/.mcli/mcli.db has been recreated from a backed-up mnemonic, with an order in progress:

$ mostro-cli restore
🔄 Restore Session Response
📋 Found 1 pending order(s):
  1. Order ID: <uuid>
     Trade Index: 7
     Status: FiatSent

✅ Session restore completed successfully!

$ mostro-cli release -o <uuid>
no rows returned by a query that expected to return at least one row

The restore reports success, and the very next step fails.

Root cause

Action::RestoreSession in src/parser/dms.rs:826 iterates restore_data.restore_orders and restore_data.restore_disputes purely to println! them:

for (i, order_info) in restore_data.restore_orders.iter().enumerate() {
    println!("  {}. Order ID: {}", i + 1, order_info.order_id);
    println!("     Trade Index: {}", order_info.trade_index);
    println!("     Status: {:?}", order_info.status);
    println!();
}

No Order is constructed and Order::save is never called, so the orders table is untouched. src/cli/restore.rs has a &Context (and therefore the pool) available — it is passed down to print_commands_results — so nothing structural prevents persisting here.

Impact

Every command that resolves an order through Order::get_by_id fails on a restored order. All of these hard-error, none degrade gracefully:

Command Call site
release, cancel, fiatsent, dispute src/cli/send_msg.rs:89, :159
addinvoice src/cli/add_invoice.rs:15
addbondinvoice src/cli/add_bond_invoice.rs:20
rate src/cli/rate_user.rs:39
senddm src/cli/send_dm.rs:45
dmtouser src/cli/dm_to_user.rs:21
getdmuser src/cli/get_dm_user.rs:31
sendadmindmattach src/cli/send_admin_dm_attach.rs:212

Worth noting the failure is opaque: release surfaces sqlx's no rows returned by a query that expected to return at least one row, which gives the user no clue that the order is simply absent from the local cache.

Why this should be tractable

What those commands actually need from the row is order.trade_keys — the keypair the order was opened with. That is derivable, because RestoredOrdersInfo (mostro-core 0.14.1, src/message.rs:484) carries exactly the missing piece:

pub struct RestoredOrdersInfo {
    pub order_id: Uuid,
    pub trade_index: i64,
    pub status: String,
}

User::get_trade_keys(pool, trade_index) already derives a keypair from an index, so trade_index → trade keys → a usable local row is a short path. RestoredDisputesInfo likewise carries order_id, trade_index, status, initiator and solver_pubkey.

Suggested approach

  1. In the RestoreSession handler, for each restored order: derive the trade keys from trade_index, and upsert an orders row keyed on order_id (upsert rather than insert, so re-running restore is idempotent and does not clobber a row that is already richer).

  2. Decide what to do about the columns the payload does not carry. orders declares kind, status, amount, fiat_code, fiat_amount, payment_method and premium as NOT NULL (src/db.rs:29-46), so a row cannot be written from RestoredOrdersInfo alone. Two options:

    • fetch the public kind-38383 event for each order id and fill the real values — the ordersinfo path already does this kind of lookup, so it could be reused;
    • or relax those columns to nullable and treat a restored row as a stub that later messages backfill.

    The first keeps the local cache faithful; the second is smaller but spreads Option handling into the printing code.

  3. Consider persisting disputes too, so a restored user can keep talking to their solver.

  4. Whatever is chosen, restore should stop printing ✅ Session restore completed successfully! when the orders were only displayed — the message currently overstates what happened.

Acceptance

After mostro-cli restore on a database rebuilt from the mnemonic, an order that Mostro reports as active can be carried to completion — at minimum release / fiatsent / senddm work against it without further manual steps.

Lingua principale
Rust
Stelle
39
Fork
16
Merge medio
11h 7m
PR unite (30g)
7

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MostroP2P/mostro-cli

Tutte le issue di MostroP2P/mostro-cli

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.