taler-docs

commit de75e1e8d86244ed7094c1e31c35d7d045bb6725
parent e0e7eca1b3042d6667013f1878831eb28d127007
Author: Iván Ávalos <avalos@disroot.org>
Date:   Tue, 11 Aug 2026 17:57:36 +0200

dd92: pending withdrawals are resumable from another device

Diffstat:
M
design-documents/092-incremental-backup-sync.rst
 | 
29
++++++++++++++++++-----------

1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/design-documents/092-incremental-backup-sync.rst b/design-documents/092-incremental-backup-sync.rst
@@ -901,9 +901,12 @@ reserves (and with them the ability to recoup a restored coin) are backed
 up by the ``add-reserve`` family, and the withdrawal family
 (``withdrawal-start`` / ``withdrawal-abort`` / ``withdrawal-done`` /
 ``withdrawal-fail``, referencing the reserve by
-``[exchangeBaseUrl, reservePub]``) restores the withdrawal transactions
-themselves; a withdrawal that was still pending on the other device
-cannot have its in-flight bank leg continued, and the refresh groups are
+``[exchangeBaseUrl, reservePub]``, and carrying the ``wgInfo`` with the
+``taler://withdraw`` URI that identifies the bank's operation) restores
+the withdrawal transactions themselves and lets a restored wallet
+continue a pending one -- the bank's operation is keyed by that URI, and
+the reserve key pair and the coin seed are in the backup too; only an
+expired bank operation cannot be resumed.  The refresh groups are
 still not backed up, so a restored refreshed coin cannot be
 recouped-refreshed until the refresh family lands (recoup of a withdrawn
 coin works,
@@ -1061,12 +1064,13 @@ User initiates a withdrawal.
 
 The increment references the reserve by ``[exchangeBaseUrl, reservePub]``
 (see the "Add a reserve" section): the restored wallet takes the reserve's
-key pair from the reserve record.  The in-flight bank interaction of a
-pending withdrawal is not part of the backup -- only the constant
-parameters and the terminal increments travel, so a restored wallet shows
-the withdrawal's history (start, then done, failed or aborted), while a
-withdrawal that was still pending on the other device cannot have its bank
-leg continued here.
+key pair from the reserve record.  It also carries the ``wgInfo`` -- for a
+bank-integrated withdrawal, the ``taler://withdraw`` URI that identifies
+the bank's withdrawal operation.  That URI, the reserve key pair and the
+coin seed (all in the backup) are everything a restored wallet needs to
+continue a withdrawal that was still pending on the other device; the only
+thing that cannot be resumed is a bank operation the bank has already
+expired or deleted.
 
 .. ts:def:: WithdrawalStartInc
 
@@ -1079,6 +1083,7 @@ leg continued here.
      timestampStart: TalerPreciseTimestamp;
      restrictAge?: number;
      instructedAmount?: AmountString;
+     wgInfo: WgInfo;
    }
 
 * **Primary key:** ``[withdrawalGroupId]``
@@ -2374,8 +2379,10 @@ Definition of done
   The withdrawal families are implemented
   (``withdrawal-start`` / ``withdrawal-abort`` / ``withdrawal-done`` /
   ``withdrawal-fail``, referencing the reserve by
-  ``[exchangeBaseUrl, reservePub]``); a pending withdrawal's in-flight
-  bank leg is not portable, so only its history (and its coins) restore.
+  ``[exchangeBaseUrl, reservePub]`` and carrying the ``wgInfo`` with the
+  ``taler://withdraw`` URI of the bank's operation); a restored wallet
+  can continue a pending withdrawal (an expired bank operation is the
+  only thing that cannot be resumed).
   The refresh groups are not backed up, so a restored refreshed coin
   cannot be recouped-refreshed; the token family is
   blocked on a schema redesign: the increments in this document model