From c68cb55278b9e1d6ce5cfebb5f948ccbf56be41e Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sat, 8 Apr 2023 17:14:27 +0200 Subject: whitespace --- .../037-wallet-transactions-lifecycle.rst | 38 +++++++++++----------- 1 file changed, 19 insertions(+), 19 deletions(-) (limited to 'design-documents') diff --git a/design-documents/037-wallet-transactions-lifecycle.rst b/design-documents/037-wallet-transactions-lifecycle.rst index 3cc807e4..8a8df2e2 100644 --- a/design-documents/037-wallet-transactions-lifecycle.rst +++ b/design-documents/037-wallet-transactions-lifecycle.rst @@ -21,8 +21,8 @@ Common States The following states apply to multiple different transactions. Only pending and aborting have transaction-specific sub-states, denoted by ``state(substate)``. -``initial``: The initial state is the result a user interaction. A transaction -may have more than one initial state (if it is started in multiple ways) or none +``initial``: The initial state is the result a user interaction. A transaction +may have more than one initial state (if it is started in multiple ways) or none (if it's the result of another process) ``pending``: A pending transaction waits for some external event/service. @@ -48,9 +48,9 @@ complete the transaction, the wallet is taking active steps to abort it. The ``l indicates errors the wallet experienced while taking active steps to abort the transaction. ``aborted``: Similar to a ``done`` transaction, but the transaction was successfully aborted -instead of successfully finished. It will have the information of when (timestamp) it was +instead of successfully finished. It will have the information of when (timestamp) it was aborted and in which pending sub-state the abort action was initiated. Also, we can -include more information information relevant to the transaction in `abortReason` +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. @@ -83,12 +83,12 @@ states: ``pending(*)`` and ``aborting(*)``. Should we show the retry timeout in the UI somewhere? Should we show it in dev mode? - SEBASJM: Since the wallet will retry anyway, maybe is better if we replace the "retry" + SEBASJM: Since the wallet will retry anyway, maybe is better if we replace the "retry" button with a "try now" button and a side text "retrying in xxx seconds" -``[action:abort]``: Aborting a transaction either directly stops processing for the -transaction and puts it in an ``aborted`` state or starts the necessary steps to -actively abort the transaction (e.g. to avoid losing money) and puts it in an +``[action:abort]``: Aborting a transaction either directly stops processing for the +transaction and puts it in an ``aborted`` state or starts the necessary steps to +actively abort the transaction (e.g. to avoid losing money) and puts it in an ``aborting`` state. ``[action:suspend]``: Suspends a pending transaction, stopping any associated network activities, but with a chance of trying @@ -115,15 +115,15 @@ Common pending sub-states --------------------------------- During the pending state the transaction can go through several sub-states before -reaching a final state. Some of this sub-states are shared between different +reaching a final state. Some of this sub-states are shared between different transaction types: ``kyc-required``: The transaction can't proceed because the user needs to actively -finish a KYC process. Part of a withdrawal process or peer-to-peer push credit. +finish a KYC process. Part of a withdrawal process or peer-to-peer push credit. ``aml-required``: The transaction can't proceed because the user needs to wait for -the exchange operator to conclude an AML investigation by the staff at the exchange. -The user is not expected to take any action and should just wait for the investigation +the exchange operator to conclude an AML investigation by the staff at the exchange. +The user is not expected to take any action and should just wait for the investigation to conclude. Part of a withdrawal process or peer-to-peer push credit. ``aml-frozen``: The staff at the exchange decided that the account needed to be frozen. @@ -162,7 +162,7 @@ user. So special-casing this and testing this is IMO just not worth it. exchange. (??) is this needed? let say that the money is wired but the signal - never of the bank confirmation reached the wallet, what should happen? + never of the bank confirmation reached the wallet, what should happen? * ``[poll-success] => pending(exchange-wait-reserve)`` * ``[action:abort] => aborting(wallet-to-bank)`` @@ -205,7 +205,7 @@ user. So special-casing this and testing this is IMO just not worth it. * ``aborted(partially-withdrawn)``: In this state, the wallet should show how much money arrived into the wallet - and the rest of the money will be sent back to the originating bank account + and the rest of the money will be sent back to the originating bank account after ``$closing_delay``. * ``done`` @@ -254,7 +254,7 @@ instructedAmount, effectiveAmount and the affectedAmount (partially effective am of transitioning the UI into a ``pending(repurchase-session-reset)`` on a different transaction (which before was in ``done``). - (??) should not reset another transaction? + (??) should not reset another transaction? * ``pending(proposed)`` @@ -284,7 +284,7 @@ Submit coin by coin (or in bulk groups) until payment is complete. * ``pending(refundable)`` -The payment succeed but if auto-refund-check is active it will be checking for refunds +The payment succeed but if auto-refund-check is active it will be checking for refunds * ``[auto-refund-timeout] => done`` @@ -334,7 +334,7 @@ A refund is a pseudo-transaction that is always associated with a merchant payme A failed refund can technically still transition to ``done``, because the wallet doesn't query some refund resource, but the purchase for refunds. Thus, a previously - failed refund can suddenly transition to ``done``. + failed refund can suddenly transition to ``done``. (??) separate transient error vs permanent error ? @@ -409,7 +409,7 @@ Submit coin by coin (or in bulk groups) until deposit is completed. * ``[action:abort] => aborting(refund)`` * ``[processed-success] => pending(track)`` - * ``[processed-error] => aborting(refresh)`` + * ``[processed-error] => aborting(refresh)`` * ``pending(track)`` @@ -605,7 +605,7 @@ Wallet read the taler:// URI * ``pending(refundable)`` -The payment succeed but if auto-refund-check is active it will be checking for refunds +The payment succeed but if auto-refund-check is active it will be checking for refunds * ``[auto-refund-timeout] => done`` -- cgit v1.2.3