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

Restore: durable background restore (restore_id, persisted pending request, late replies applied)

Open
  • Is something wrong?
#219 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
dart
Domain
mobile

Research direction

Start by reading the prerequisite issue #215 and the related idempotency issue #218, then trace the restore dispatcher, RestoreData handling, and local state used by the restore screen. Done means pending restores survive navigation and app restarts, late and duplicate replies are handled safely, and users can explicitly abandon a restore.

Written by the indexing model from the issue text.

Description

area: identity area: protocol feature priority: high

Sub-issue of #142. Depends on: #215.

Problem

The handshake currently waits on a fixed 10-second in-process timeout. The daemon's restore window is on the order of an hour, so a valid reply routinely arrives after the waiter is gone — and is then discarded. Logging the late reply only makes the loss visible; it does not fix it.

Restore is not a foreground RPC. It is a durable background operation.

Scope
  • Give each restore an explicit restore_id / request_id, echoed by progress, final and error messages.
  • Persist the pending restore locally, so it survives navigating away from the screen and a full app restart.
  • The dispatcher must apply a valid final RestoreData even when no UI waiter is attached.
  • Drop the fixed short timeout in favour of the durable model; keep a bounded retry/abort path so a restore cannot hang forever with no way out.
  • Late, duplicate or out-of-order replies must be handled safely (this pairs with the idempotency requirement in #218).
Acceptance criteria
  • A reply arriving well after the request (> 10s, and after an app restart) is still applied
  • Navigating away from the restore screen does not discard the result
  • A restore in flight is visible in local state after a cold start
  • A duplicate final reply for the same restore_id is a no-op
  • The user can cancel/abandon a restore explicitly, and the abandoned restore_id is then ignored
Dominant language
Dart
Stars
11
Forks
9
Avg merge
21h 30m
Merged PRs (30d)
225

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.