@unicitylabs/sphere-sdk 0.9.1-dev.12 → 0.9.1-dev.14

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,11 +2868,19 @@ 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;
     /**
@@ -2882,13 +2893,19 @@ declare class PaymentsModule {
      * (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,11 +2868,19 @@ 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;
     /**
@@ -2882,13 +2893,19 @@ declare class PaymentsModule {
      * (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.js

@@ -11349,6 +11349,7 @@ function computeHistoryDedupKey(type, tokenId, transferId) {
 }
 var MAX_SYNCED_HISTORY_ENTRIES = 5e3;
 var MAX_HISTORY_HYDRATION_PAGES = 100;
+var MAX_PR_HYDRATION_PAGES = 100;
 var SEND_ENGINE_OP_TIMEOUT_MS = 6e4;
 var DELIVERY_POLL_INTERVAL_MS = 3e4;
 function enrichWithRegistry(info) {
@@ -11676,10 +11677,13 @@ var PaymentsModule = class _PaymentsModule {
   /** Coalesces concurrent payment-request pump runs. */
   prPumpInFlight = null;
   /**
-   * 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).
    */
   prBootstrapped = false;
   // Guard: ensure load() completes before processing incoming bundles
@@ -14528,22 +14532,28 @@ var PaymentsModule = 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.
    */
   async pumpIncomingPaymentRequests(api) {
     const persisted = await this.readPrCursorState();
     if (!this.prBootstrapped) {
-      if (persisted !== null && persisted.cursor > 0n) {
-        let scan = await api.listPaymentRequests({ role: "incoming", status: "open", since: 0n });
-        for (; ; ) {
-          for (const wire of scan.requests) this.surfaceIncomingPaymentRequest(wire);
-          if (!scan.more) break;
-          scan = await api.listPaymentRequests({ role: "incoming", status: "open", since: scan.cursor });
-        }
+      let scan = await api.listPaymentRequests({ role: "incoming", since: 0n });
+      for (let pageCount = 0; pageCount < MAX_PR_HYDRATION_PAGES; pageCount++) {
+        for (const wire of scan.requests) this.surfaceIncomingPaymentRequest(wire);
+        if (!scan.more) break;
+        scan = await api.listPaymentRequests({ role: "incoming", since: scan.cursor });
       }
       this.prBootstrapped = true;
     }
@@ -14577,17 +14587,23 @@ var PaymentsModule = class _PaymentsModule {
       return {};
     }
   }
+  /** §16 wire status → the public {@link PaymentRequestStatus} display status. */
+  static PR_WIRE_STATUS = { open: "pending", paid: "paid", declined: "rejected", expired: "expired" };
   /**
    * 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).
    */
   surfaceIncomingPaymentRequest(wire) {
-    if (wire.status !== "open") return;
     if (this.paymentRequests.some((r) => r.id === wire.id)) return;
+    const status = _PaymentsModule.PR_WIRE_STATUS[wire.status];
     const coinId = wire.assets[0]?.coinId ?? "";
     const coinDef = TokenRegistry.getInstance().getDefinition(coinId);
     const { memo: message, senderNametag } = this.decryptPaymentRequestMemo(wire);
@@ -14601,18 +14617,20 @@ var PaymentsModule = class _PaymentsModule {
       ...message !== void 0 ? { message } : {},
       requestId: wire.id,
       timestamp: wire.createdAt,
-      status: "pending"
+      status
     };
     this.paymentRequests.unshift(request);
-    this.deps?.emitEvent("payment_request:incoming", request);
-    for (const handler of this.paymentRequestHandlers) {
-      try {
-        handler(request);
-      } catch (error) {
-        logger.debug("Payments", "Payment request handler error:", error);
+    if (status === "pending") {
+      this.deps?.emitEvent("payment_request:incoming", request);
+      for (const handler of this.paymentRequestHandlers) {
+        try {
+          handler(request);
+        } catch (error) {
+          logger.debug("Payments", "Payment request handler error:", error);
+        }
       }
     }
-    logger.debug("Payments", `Incoming payment request: ${request.id} for ${request.amount} ${request.symbol}`);
+    logger.debug("Payments", `Incoming payment request: ${request.id} (${status}) for ${request.amount} ${request.symbol}`);
   }
   /**
    * Outgoing requests are a `?before=` backfill view (§16 — newest-first, no