WalletSendReport class sealed

FR-26 — what the package tells a host about the send flow the host's own entry point opened (WalletSendEntry.push).

WHY THIS EXISTS. The entry's navigation future completes when the send screen POPS, and a pop is true of the user who paid and of the user who backed out alike — one signal covering both branches, committing to neither. A host that composes a payment record on it can put a false claim of payment in front of the payee. This family is the branch the pop refused to take.

THE HOST DECIDES NOTHING ABOUT THE MONEY. Every variant is a statement about what the WALLET did; the wallet's own surfaces (activity, the in-flight cue, the balance) remain the authority on what happens next — a transaction that did not reach the network is re-broadcast by the resubmission machinery without the host's involvement.

PAYLOAD DISCIPLINE (§5.4). A report carries transaction identifiers, counts and the host's own correlationId — never the recipient, the memo, or anything else the user typed, and never the amount with ONE deliberate exception: a TAGGED WalletSendTransactionCreated carries WalletSendTransactionCreated.recipientAmountZat (FR-46) — the host already knows the recipient it locked and asked for this figure; an untagged report carries no amount at all. Nothing here is logged by the package. A txid is a §5.4 never-log item that this seam deliberately hands to third-party code, so a host holds it to the same bar: it is a payment identifier, not a display string.

TWO LIMITS, STATED SO A HOST DOES NOT DISCOVER THEM IN PRODUCTION:

• The report is PROCESS-LOCAL and cannot be restored. It travels on the route's extra, which does not survive Android process death: a restored /wallet/send opens with no prefill and no channel, and the future the host was awaiting dies with the process. A host that persists a pending record must keep its own reconciliation path (the wallet's activity surface, joined on the txid it may not yet have) rather than assuming this future always arrives.
• Only the FIRST payment of a flow is reported. The channel is one-shot. Once a report is delivered the package removes every affordance that could spend again from that entry — "Send another" AND "Try again" — and a terminal is only published for a flow that can no longer spend, so a denied prompt or a refused sign leaves the channel open for the payment the user actually makes. Still: a host must not treat one report as proof that exactly one payment was ever made.

Implementers

• WalletSendAlreadySubmitted
• WalletSendNoTransaction
• WalletSendQueuedOffline
• WalletSendTransactionCreated
• WalletSendUnclassified

Properties

correlationId → String?

The opaque token the host put on WalletSendRequest.correlationId, echoed back verbatim. null when the host set none.

final

hashCode → int

The hash code for this object.

no setter, inherited

runtimeType → Type

A representation of the runtime type of the object.

no setter, inherited

Methods

noSuchMethod(Invocation invocation) → dynamic

Invoked when a nonexistent method or property is accessed.

inherited

toString() → String

A string representation of this object.

inherited

Operators

operator ==(Object other) → bool

The equality operator.

inherited