Disconnect Reconnect

Test disconnect and reconnect after restart

A wallet connection is not fully qualified by one successful Connect tap. EdgeORE also needs to show what happens when authorization is revoked, the app restarts and a later connection is requested. These checks are readier to run than a transfer because they do not require signing a payment. They should be completed and preserved independently so a transaction test begins from a known session state.

Define disconnect acceptance

Start with a visibly connected EdgeORE account whose authorization success was actually observed. Capture the connected card, then choose Disconnect. Approve any wallet revocation interaction the implementation requires. The app should clear the connected account and authorization context only according to its actual completed result, and it should show an error if revocation fails. A button changing its label alone is not enough to prove the wallet authorization was invalidated.

Avoid logging raw auth tokens while diagnosing the flow. They are credentials, even when they are not private signing keys. A session note can describe that a token was cleared or a revocation result returned without publishing its value. If an implementation stores a token for reconnect, describe the storage boundary and test it deliberately rather than inferring behavior from a SDK quickstart.

Test a fresh connection

After disconnect, request Connect again. Confirm that the selected account and expected approval experience appear. If the wallet reuses an authorization, verify that this matches the intended revocation semantics; otherwise document the discrepancy. The goal is a trustworthy user-visible state, not forcing every wallet to show exactly the same number of dialogs. Wallet-specific behavior belongs in the environment note.

Next, close or force-stop EdgeORE after a completed connection, reopen it and inspect the connection state. Do not confuse restarting the app with interrupting a transfer. This test concerns authorization/session restoration. A restarted app may need a fresh wallet association, and the expected behavior should be read from the implementation under test. Capture what occurs rather than prescribing success after the fact.

Distinguish account continuity

When reconnecting, compare the returned public key with the earlier selected account. If the user chooses another wallet account, budgets and pending operations must remain attributed to their original signer and cluster. The app should not attach an older transfer reservation to a newly selected address merely because both were used on the same device. Account identity is part of the operation record, not a cosmetic label.

Try a refusal during reconnect and ensure the UI reports it without erasing historical operation evidence. Try an RPC outage after reconnect and keep balance availability distinct from wallet state. These cases make the gate stronger because many apparently successful interfaces fail when an external read is missing. The wallet's authority and the RPC's availability are different systems.

Preserve the sequence

Store connected, disconnected and restarted/reconnected screenshots with a short ordered note. Identify the APK and wallet versions, runtime, times and any unexpected prompt. Mark each action separately. The latest session report still leaves these checks NOT_RUN, so the website cannot close them merely because instructions now exist. Once the sequence is genuinely observed, update only the corresponding ledger rows and leave transfer, recovery and real-receipt verification unchanged until they are tested.

---

Wiki home · Qualification updates · Sources and credits