@unicitylabs/sphere-sdk 0.9.1-dev.11 → 0.9.1-dev.13

package/dist/core/index.d.cts

@@ -2125,10 +2125,13 @@ declare class PaymentsModule {
     /** Coalesces concurrent payment-request pump runs. */
     private prPumpInFlight;
     /**
-     * Set after the once-per-session `status=open` bootstrap scan: the surfaced
-     * incoming list is in-memory only, so still-open requests BELOW the
-     * persisted cursor must be recovered at session start (bounded by the §5.5
-     * per-payer open cap).
+     * Set after the once-per-session full incoming hydration (#556): the surfaced
+     * incoming list is in-memory only, so on a fresh engine the CURRENT state of
+     * ALL incoming requests — open AND resolved (paid/declined/expired) — must be
+     * rebuilt from a `role=incoming&since=0` pull, not just the still-open ones.
+     * A status-filtered bootstrap (the pre-#556 `status=open` scan) dropped
+     * requests resolved in a PRIOR session, so the payer reopened and the
+     * 'Paid Successfully' request was gone (twin of #521/#549).
      */
     private prBootstrapped;
     private loadedPromise;
@@ -2865,20 +2868,44 @@ declare class PaymentsModule {
      * mailbox-cursor pattern: the persisted `{cursor, syncEpoch}` is the resume
      * point; a `syncEpoch` change (server restore — §5.4) voids cursor
      * continuity, so the tail re-pulls from 0 and the id-dedup in
-     * {@link surfaceIncomingPaymentRequest} absorbs the replays. Because the
-     * surfaced list is in-memory only, each session ALSO starts with one
-     * `status=open` bootstrap scan from 0 — still-open requests below the
-     * cursor (bounded by the §5.5 per-payer open cap) are recovered; resolved
-     * ones are not re-surfaced.
+     * {@link surfaceIncomingPaymentRequest} absorbs the replays.
+     *
+     * Because the surfaced list is in-memory only, each session FIRST runs one
+     * full incoming hydration from `since=0` with NO status filter (#556 —
+     * mirrors {@link hydrateHistoryFromServer}): a fresh engine rebuilds the
+     * CURRENT state of ALL incoming requests — open AND resolved — so a request
+     * paid/declined/expired in a PRIOR session is still present (with its
+     * resolved status) instead of vanishing once the cursor advanced past it.
+     * Hydration NEVER fires the new-incoming handlers/events for resolved
+     * requests — only `open` ones notify (the status-aware
+     * {@link surfaceIncomingPaymentRequest}) — so reopening can't spam stale
+     * 'new request' notifications. After hydration the `since`-cursor delta poll
+     * picks up live updates from the resume point.
      */
     private pumpIncomingPaymentRequests;
+    /**
+     * Decrypt a payment-request's recipient-addressed memo envelope into
+     * `{ memo, senderNametag }` (the requester's message + nametag). The key is
+     * the ECDH shared secret between THIS wallet (the payer) and the requester's
+     * chain pubkey (`wire.fromPubkey`) — symmetric with the requester's
+     * create-time derivation. Returns an empty bundle (and logs at debug) on any
+     * absence/failure so the incoming view never wedges on an unreadable memo
+     * (PR twin of #546/#547).
+     */
+    private decryptPaymentRequestMemo;
+    /** §16 wire status → the public {@link PaymentRequestStatus} display status. */
+    private static readonly PR_WIRE_STATUS;
     /**
      * Map a §16 wire request onto the public {@link IncomingPaymentRequest}
-     * surface and notify (event + handlers). Only `open` requests are
-     * actionable; the in-memory id-dedup doubles as the replay guard for
-     * cursor resets. Multi-asset requests surface their first asset (the
-     * module's request surface is single-asset; module-created requests
-     * always are).
+     * surface, deduped by id (the in-memory id-dedup doubles as the replay guard
+     * for cursor resets). Requests of EVERY status are surfaced so a reloaded
+     * thin wallet rebuilds the CURRENT state of its incoming view (#556) — open
+     * ones land as actionable `pending`, resolved ones carry their paid/declined
+     * (→ `rejected`)/expired status. Only `open` requests fire the new-incoming
+     * event + handlers; resolved requests are folded into the list silently, so a
+     * reload (or a `syncEpoch` re-pull) never re-notifies for already-resolved
+     * requests. Multi-asset requests surface their first asset (the module's
+     * request surface is single-asset; module-created requests always are).
      */
     private surfaceIncomingPaymentRequest;
     /**

package/dist/core/index.d.ts

@@ -2125,10 +2125,13 @@ declare class PaymentsModule {
     /** Coalesces concurrent payment-request pump runs. */
     private prPumpInFlight;
     /**
-     * Set after the once-per-session `status=open` bootstrap scan: the surfaced
-     * incoming list is in-memory only, so still-open requests BELOW the
-     * persisted cursor must be recovered at session start (bounded by the §5.5
-     * per-payer open cap).
+     * Set after the once-per-session full incoming hydration (#556): the surfaced
+     * incoming list is in-memory only, so on a fresh engine the CURRENT state of
+     * ALL incoming requests — open AND resolved (paid/declined/expired) — must be
+     * rebuilt from a `role=incoming&since=0` pull, not just the still-open ones.
+     * A status-filtered bootstrap (the pre-#556 `status=open` scan) dropped
+     * requests resolved in a PRIOR session, so the payer reopened and the
+     * 'Paid Successfully' request was gone (twin of #521/#549).
      */
     private prBootstrapped;
     private loadedPromise;
@@ -2865,20 +2868,44 @@ declare class PaymentsModule {
      * mailbox-cursor pattern: the persisted `{cursor, syncEpoch}` is the resume
      * point; a `syncEpoch` change (server restore — §5.4) voids cursor
      * continuity, so the tail re-pulls from 0 and the id-dedup in
-     * {@link surfaceIncomingPaymentRequest} absorbs the replays. Because the
-     * surfaced list is in-memory only, each session ALSO starts with one
-     * `status=open` bootstrap scan from 0 — still-open requests below the
-     * cursor (bounded by the §5.5 per-payer open cap) are recovered; resolved
-     * ones are not re-surfaced.
+     * {@link surfaceIncomingPaymentRequest} absorbs the replays.
+     *
+     * Because the surfaced list is in-memory only, each session FIRST runs one
+     * full incoming hydration from `since=0` with NO status filter (#556 —
+     * mirrors {@link hydrateHistoryFromServer}): a fresh engine rebuilds the
+     * CURRENT state of ALL incoming requests — open AND resolved — so a request
+     * paid/declined/expired in a PRIOR session is still present (with its
+     * resolved status) instead of vanishing once the cursor advanced past it.
+     * Hydration NEVER fires the new-incoming handlers/events for resolved
+     * requests — only `open` ones notify (the status-aware
+     * {@link surfaceIncomingPaymentRequest}) — so reopening can't spam stale
+     * 'new request' notifications. After hydration the `since`-cursor delta poll
+     * picks up live updates from the resume point.
      */
     private pumpIncomingPaymentRequests;
+    /**
+     * Decrypt a payment-request's recipient-addressed memo envelope into
+     * `{ memo, senderNametag }` (the requester's message + nametag). The key is
+     * the ECDH shared secret between THIS wallet (the payer) and the requester's
+     * chain pubkey (`wire.fromPubkey`) — symmetric with the requester's
+     * create-time derivation. Returns an empty bundle (and logs at debug) on any
+     * absence/failure so the incoming view never wedges on an unreadable memo
+     * (PR twin of #546/#547).
+     */
+    private decryptPaymentRequestMemo;
+    /** §16 wire status → the public {@link PaymentRequestStatus} display status. */
+    private static readonly PR_WIRE_STATUS;
     /**
      * Map a §16 wire request onto the public {@link IncomingPaymentRequest}
-     * surface and notify (event + handlers). Only `open` requests are
-     * actionable; the in-memory id-dedup doubles as the replay guard for
-     * cursor resets. Multi-asset requests surface their first asset (the
-     * module's request surface is single-asset; module-created requests
-     * always are).
+     * surface, deduped by id (the in-memory id-dedup doubles as the replay guard
+     * for cursor resets). Requests of EVERY status are surfaced so a reloaded
+     * thin wallet rebuilds the CURRENT state of its incoming view (#556) — open
+     * ones land as actionable `pending`, resolved ones carry their paid/declined
+     * (→ `rejected`)/expired status. Only `open` requests fire the new-incoming
+     * event + handlers; resolved requests are folded into the list silently, so a
+     * reload (or a `syncEpoch` re-pull) never re-notifies for already-resolved
+     * requests. Multi-asset requests surface their first asset (the module's
+     * request surface is single-asset; module-created requests always are).
      */
     private surfaceIncomingPaymentRequest;
     /**