Durable Recovery

Recover after an interrupted submission

Restart recovery exists because a mobile process can disappear at any point in a transfer. EdgeORE should resume observation from durable state rather than infer what happened from the last screen the user remembers. Its operation record stores exact message information, signature, signed bytes, attempts, observations and state. Atomic, fsynced transitions mean a visible state change should follow successful persistence, not get ahead of it.

Understand the interruption windows

An app can stop before signing, during a wallet session, after signed bytes return, before submission, after SUBMIT_ATTEMPTED is persisted or after the RPC accepted the transfer. Those windows have different consequences. Unsigned drafts or interrupted wallet sessions can be abandoned according to policy. Signed bytes never submitted can be discarded through the supported action. Once submission is attempted, uncertainty must be reconciled rather than erased.

A damaged operation store must fail closed. Treating corrupt storage as an empty pending list would lose the exact records needed to avoid duplicate sends and budget mistakes. The user should see that transfers are disabled because the state is unavailable. Recovery tooling may be required, but a convenient reset is not an acceptable silent substitute for a trustworthy store.

Perform the runtime recovery test

Begin with an explicitly reviewed and signed devnet operation. Start Send, then interrupt the app while submission is visibly in progress. Preserve what happened and the timing as accurately as the environment allows. Reopen EdgeORE, find the same operation and use Observe status. The expected action is read-only reconciliation, not an automatic resend. Capture the restored operation and subsequent observation.

adb shell am force-stop com.edgeore.app
adb shell am start -n com.edgeore.app/.MainActivity

The commands alone do not prove the interruption landed inside the send window. If the transfer already completed before the stop, you tested persistence after completion, which is useful but different. Do not label it interrupted-submit recovery. A controlled test may need logs or a test harness to locate the window without deliberately weakening production behavior.

Inspect reconciliation semantics

Recovery reads block height and signature status. An expired validity window does not establish that a previously submitted transaction failed. The operation may remain OUTCOME_UNKNOWN and keep its reservation. A chain-confirmed failure or success can settle the corresponding state when supported by a trustworthy observation. Malformed RPC results should be unavailable, not interpreted as a clean missing signature.

If the app died before appending a receipt, startup should repair the missing local record from its durable operation state as implemented. That receipt still needs its evidence dimensions understood. A locally repaired receipt is not a new on-chain transaction and should not trigger another submission. Stable operation identity keeps recovery, budget accounting and receipt generation from becoming three independent stories about the same action.

Preserve the gate

The recovery evidence should name the operation, source/APK identity, interruption point, restored state, Observe action and chain response. If no repeated submission occurred, preserve the supporting coordinator or network evidence rather than inferring it only from a single explorer entry. If the runtime cannot expose that level of detail, state the limitation. The latest session still leaves this gate NOT_RUN; a restart reconnect test or a previously confirmed transaction does not close it.

---

Wiki home · Qualification updates · Sources and credits