Restore: deterministic clean-install test (index resync, late reply, cached order, restart mid-recovery)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start by reading the restore module and its existing ignored live-regtest round-trip test; identify how the dispatcher accepts crafted RestoreData payloads and how restore state is persisted across restart. Add deterministic CI coverage for all five listed cases, then run the restore tests and check that module coverage reaches 80%. Done means all cases pass without a live daemon, while the live-regtest test remains a separate ignored smoke test.
Written by the indexing model from the issue text.
Description
Sub-issue of #142. Depends on: #218, #219.
The #[ignore]d regtest round-trip proves the handshake, but it cannot catch the failure modes that matter for #142 — most of them are ordering and lifetime bugs that a happy-path, same-process test hides.
Required cases
A deterministic clean-install (reinstall-style) test must cover:
- A recovered index greater than 1 — and the next new trade uses a fresh index, not a recovered one (#217)
- A delayed response beyond 10 seconds — still applied (#219)
- An order already present in the cache before the restore — corrected to
is_mine = true(#218) - Restart during recovery — the pending restore survives and completes, without duplicating state
- Re-applying the same snapshot — no duplicated trades, sessions, disputes or mappings
Notes
- Must be deterministic and CI-runnable — not dependent on a live daemon. Drive the dispatcher with crafted
RestoreDatapayloads rather than a real network round-trip. - Keep the live-regtest E2E test as a separate,
#[ignore]d smoke test.
Acceptance criteria
- All five cases above covered and green in CI
- Coverage for the restore module meets the project's 80% minimum
- Dominant language
- Dart
- Stars
- 11
- Forks
- 9
- Avg merge
- 12h 41m
- Merged PRs (30d)
- 265
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MostroP2P/app
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Add-invoice screen stays on "Sent, waiting for the node" after a late acceptance on a sell orderOpenbug priority: medium
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
area: ui
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
MostroP2P/app#341 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
bug product: very_good_flutter_plugin
Difficulty 1/5 1-3 hours Newbie friendliness 78/100
VeryGoodOpenSource/very_good_templates#654 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
Maintainers usually reply within 1 day
-
Server never consumes the request body on early-error paths: _sinkIncoming does not resume the paused subscriptionMay be free again A pull request for this issue was closed without being merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
[BUG][All] VLESS URIs with flow=xtls-rprx-vision-udp443 are silently dropped on subscription importOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
simonoppowa/OpenNutriTracker#1336 ·
Maintainers usually reply within 1 day