wallet-core/packages/taler-wallet-core/src/operations
2022-08-29 13:23:22 -03:00
..
backup moved wireInfo and denomInfo into taler-util so it can be used from the ui 2022-08-18 16:02:16 -03:00
balance.ts implement peer to peer push payments 2022-08-16 17:55:12 +02:00
common.ts wallet: make retries more robust and consistent 2022-03-29 13:48:51 +02:00
deposits.ts moved wireInfo and denomInfo into taler-util so it can be used from the ui 2022-08-18 16:02:16 -03:00
exchanges.ts wallet-core: fix revocation, re-introduce reserves object store 2022-08-26 01:18:01 +02:00
merchants.ts wallet: address crypto worker hang and warning about worker termination 2022-03-23 13:11:36 +01:00
pay.ts add delivery info in the parse contract terms and a function to get info from a proposalId 2022-08-08 13:53:04 -03:00
peer-to-peer.ts wallet-core: put taler:// URIs in transactions list 2022-08-24 22:42:30 +02:00
pending.ts wallet-core: fix revocation, re-introduce reserves object store 2022-08-26 01:18:01 +02:00
README.md wallet: make retries more robust and consistent 2022-03-29 13:48:51 +02:00
recoup.ts wallet-core: fix revocation, re-introduce reserves object store 2022-08-26 01:18:01 +02:00
refresh.ts wallet-core: only schedule auto-refresh check if exchange update has no last error 2022-05-31 15:44:22 +02:00
refund.ts -removing bad console log 2022-06-01 11:35:50 -03:00
testing.ts integration tests: various fixes 2022-08-25 23:35:29 +02:00
tip.ts fix: update retry info before return 2022-05-18 15:57:10 -03:00
transactions.ts wallet-core: put taler:// URIs in transactions list 2022-08-24 22:42:30 +02:00
withdraw.test.ts wallet-core: implement age restriction support 2022-04-27 00:50:17 +02:00
withdraw.ts add senderWire to the withdrawal group again, group payto to avoid duplication 2022-08-29 13:23:22 -03: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.