taler-docs

commit b2125ad3ad713f54aaace02d77dda88392a056c6
parent 676f0a9e08b910a44472a896b5bc5c7dea2cc646
Author: Florian Dold <florian@dold.me>
Date:   Mon, 10 Jun 2024 16:03:57 +0200

DD37: finalizing state

Diffstat:
M
design-documents/037-wallet-transactions-lifecycle.rst
 | 
11
++++++++---
M
images/transaction-common-states.dot
 | 
7
++++++-

2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/design-documents/037-wallet-transactions-lifecycle.rst b/design-documents/037-wallet-transactions-lifecycle.rst
@@ -48,6 +48,11 @@ There are some other distinctions for pending transactions:
   object with details about what happened during the last attempt to proceed
   with the transaction.
 
+``finalizing``: A finalizing transaction is functionally similar to a ``pending`` transaction,
+but is not shown to the user as a pending transaction. It is effectively finished from a user's
+perspective, but some processing can happen on the transaction that might lead to some
+other state than ``done``.
+
 ``done``: A transaction that is done does not require any more processing.  It also
 never has a ``lastError`` but is considered successful.
 
@@ -381,16 +386,16 @@ Transaction Type: Payment to Merchant
     abort the process while the payment was happening.  Note that if the
     payment was already completed (and hence the merchant refuses any
     refunds), it is theoretically possible that pressing the abort button will
-    nevertheless end up in a ``pending(auto-refund)`` state (and subsequently
+    nevertheless end up in a ``finalizing(auto-refund)`` state (and subsequently
     a ``done`` state) instead!
-  * ``[success] => pending(auto-refund)`` -- Upon receiving confirmation from
+  * ``[success] => finalizing(auto-refund)`` -- Upon receiving confirmation from
     the merchant that the purchase was completed.
   * ``[error(insufficient balance)] => aborting(pay-incomplete)`` This transition
     happens if we detect double-spending and our balance is not sufficient
     after the double-spending. It is also conceivable (but should be rare)
     that this transition happens because the offer expired.
 
-* ``pending(auto-refund)``
+* ``finalizing(auto-refund)``
 
   The payment succeed. We remain in this state as long as an auto-refund-check
   is active.  If auto refunds are not enabled, we immediately continue to
diff --git a/images/transaction-common-states.dot b/images/transaction-common-states.dot
@@ -3,6 +3,7 @@ digraph G {
   initial[label="", shape="circle"];
   pending[label="pending"];
   dialog[label="dialog", shape="box"];
+  finalizing[label="finalizing", shape="box"];
   done[label="done", shape="box"];
   aborted[label="aborted", shape="box", style="dashed"];
   aborting[label="aborting", style="dashed"];
@@ -13,7 +14,7 @@ digraph G {
   deleted[label="deleted", shape="box"];
 
   subgraph {
-    rank = same; done; failed; expired; aborted;
+    rank = same; finalizing; done; failed; expired; aborted;
   }
   subgraph {
     rank = same; pending; aborting;
@@ -48,5 +49,9 @@ digraph G {
   failed->deleted [color="blue",label="delete"];
   expired->deleted [color="blue",label="delete"];
   aborted->deleted [color="blue",label="delete"];
+  pending->pending;
+  finalizing->pending [color="green",label="progress"];
+  finalizing->done [color="green",label="progress"];
+  finalizing->deleted [color="blue",label="delete"];
   done->deleted [color="blue",label="delete"];
 }