commit cc194fc594f9e37f868a2a5707d5fd5b37ce6611
parent 859affd6de78917540d66638f1b02e011521cf77
Author: Florian Dold <florian@dold.me>
Date: Tue, 25 Apr 2023 14:12:31 +0200
clean up merchant payment tx spec
Diffstat:
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/design-documents/037-wallet-transactions-lifecycle.rst b/design-documents/037-wallet-transactions-lifecycle.rst
@@ -55,6 +55,9 @@ include more information information relevant to the transaction in `abortReason
``suspended``: Similar to a ``aborted`` transaction, but the transaction was could be
resumed and may then still succeed.
+``suspended-aborting``: Network requests or other expensive work
+to abort a transaction is paused.
+
``failed``: Similar to ``done``, but the transaction could not be completed or
possibly not even be aborted properly. The user may have lost money. In some
cases, a report to the auditor would make sense in this state.
@@ -327,18 +330,18 @@ Transaction Type: Payment to Merchant
We received a ``pay`` URI. Download (claim) the proposal from the merchant. Can fail if
the proposal was already claimed by someone else. If repurchase detection
tells us that we already paid for this product, we go immediately to
- ``delete`` state for this transaction, but with a side-effect of
+ ``failed(repurchase)`` state for this transaction, but with a side-effect of
transitioning the UI into a ``pending(repurchase-session-reset)`` on a
*different* transaction (which before was in ``done``).
- * ``[error: already claimed] => deleted`` -- the proposal was
- already claimed by someone else; we go directly into the ``deleted``
- state and only show a transient warning.
- * ``[error: invalid proposal] => deleted`` -- the merchant provided a
- proposal that is invalid (e.g. malformed contract
- terms or bad signature); we go directly into the ``deleted`` state
- and only show a transient warning.
+ A ``failed(repurchase)`` transaction will eventually be GCed (=deleted)
+ automatically.
+ * ``[error:already-claimed] => failed(already-claimed)`` -- the proposal was
+ already claimed by someone else.
+ * ``[error:invalid-proposal] => failed(invalid-proposal)`` -- the merchant provided a
+ proposal that is invalid (e.g. malformed contract
+ terms or bad signature).
* ``pending(proposed)``
@@ -347,19 +350,14 @@ Transaction Type: Payment to Merchant
* ``[action:pay-accept] => pending(submit-payment)``
* ``[action:pay-refuse] => ``aborting(unclaim)`` -- The user explicitly
decided not to proceed (at least not with this wallet).
- * ``[expired] => deleted`` -- The offer has expired before the user made any
- decision. (We can keep pending contracts even in a 'pending transaction'
- list to allow the user to choose to not proceed, but then this transition
- would clean up that list). Note that we should use this transition at
+ * ``[expired] => failed(expired)`` -- The offer has expired before the user made any
+ decision. Note that we should use this transition at
least a few seconds before the offer *actually* expires to avoid
encountering an expiration during ``pending(submit-payment)`` in most
real-world scenarios. Basically, we should prevent last-second payments to
be event attempted client-side.
-* ``aborting(unclaim)``
-
- Tells the merchant that some *other* wallet is now again free to claim this
- offer.
+ The ``failed(expired)`` might be automatically deleted upon GC.
* ``pending(submit-payment)``
