wallet-core/packages/taler-wallet-core/src/operations
2022-10-05 10:22:32 +02:00
..
backup wallet-core: use more numeric fields 2022-09-21 22:50:42 +02:00
balance.ts wallet-core: introduce easier syntax for transactions 2022-09-13 16:10:42 +02:00
common.ts wallet: make retries more robust and consistent 2022-03-29 13:48:51 +02:00
deposits.ts moving deposit group fee into taler util 2022-09-21 15:45:41 -03:00
exchanges.ts wallet-core: more info in error message 2022-10-05 10:22:32 +02:00
merchants.ts wallet: address crypto worker hang and warning about worker termination 2022-03-23 13:11:36 +01:00
pay.ts wallet-core: make basic backup work again 2022-09-21 12:40:11 +02:00
peer-to-peer.ts wallet-core: use numeric status field to allow range queries 2022-09-21 22:50:42 +02:00
pending.ts wallet-core: use more numeric fields 2022-09-21 22:50:42 +02:00
README.md wallet: make retries more robust and consistent 2022-03-29 13:48:51 +02:00
recoup.ts wallet-core: DB improvements 2022-09-21 22:50:42 +02:00
refresh.ts wallet-core: use more numeric fields 2022-09-21 22:50:42 +02:00
refund.ts -move declaration 2022-09-16 17:21:54 +02:00
testing.ts wallet-core: fix withdrawTestBalance command 2022-09-13 17:41:47 +02:00
tip.ts wallet-core: use more numeric fields 2022-09-21 22:50:42 +02:00
transactions.ts wallet-core: use numeric status field to allow range queries 2022-09-21 22:50:42 +02:00
withdraw.test.ts wallet-core: restructure denomination record for easier querying 2022-09-14 21:27:03 +02:00
withdraw.ts wallet-core: return correct status from processReserveBankStatus 2022-09-30 13:22:00 +02:00

Wallet Operations

This folder contains the implementations for all wallet operations that operate on the wallet state.

To avoid cyclic dependencies, these files must not reference each other. Instead, other operations should only be accessed via injected dependencies.

Avoiding cyclic dependencies is important for module bundlers.

Retries

Many operations in the wallet are automatically retried when they fail or when the wallet is still waiting for some external condition (such as a wire transfer to the exchange).

Retries are generally controlled by a "retryInfo" field in the corresponding database record. This field is set to undefined when no retry should be scheduled.

Generally, the code to process a pending operation should first increment the retryInfo (and reset the lastError) and then process the operation. This way, it is impossble to forget incrementing the retryInfo.

For each retriable operation, there are usually setup<Op>Retry, increment<Op>Retry and report<Op>Error operations.

Note that this means that during some operation, lastError will be cleared. The UI should accommodate for this.

It would be possible to store a list of last errors, but we currently don't do that.