View Issue Details

IDProjectCategoryView StatusLast Update
0009030Talerwallet-corepublic2024-10-02 17:37
ReporterFlorian Dold Assigned ToFlorian Dold  
PrioritylowSeverityfeatureReproducibilityhave not tried
Status resolvedResolutionfixed 
Target Version0.14 
Summary0009030: implement getTransactionsV2 API based on materialized transactions
DescriptionWe now have materialized transactions. The new getTransactionsV2 API should make use of them!

Based on the requirements of the UI, we can implement the new getTransactionsV2 request.

The main reason we want this is that currently the UIs are doing a lot of their own heavy lifting w.r.t. searching/filtering/pagination.
TagsNo tags attached.

Relationships

related to 0006588 assignedsebasjm wallet-core should support range queries for the transactions list 

Activities

MarcS

2024-07-30 23:45

developer   ~0022872

Fundamentally tx should be filtered by scopeInfo (1st param).
Then I basically need 2 types of tx: unfinished vs. finished (2nd param)
1) State == pending / dialog / finalizing/ aborting / suspended-aborting
2) State == done / aborted / suspended / failed / expired

Finally, after heavy use there could be hundreds or thousands of finished tx. Thus we need position and count parameters (e.g. pos: 200, count: 40 returns tx 200..239)
For unfinished tx I expect no more than a handful for the average user, but of course someone could send hundreds of p2p pull credit (request money) "invoices".

If position and count parameters are not set, they default to 0 (pos) and let's say 40 or 50 (count).
___
For each scope, getBalances should return not only the balance (amountAvailable), pendingIncoming and pendingOutgoing, but also countOfFinishedTx and countOfUnfinishedTx.

MarcS

2024-07-31 07:32

developer   ~0022875

Tx should have a second timestamp. The first is from the moment the tx got created.
    var timestamp: Timestamp
But, especially for peer-pull-credit, we need a "finished" timestamp which shows the time the tx finished execution.
Thus we should rename the first to "created", even though that would make it a breaking API change.
And since pending tx are not yet executed, they don't have the second, so it is optional.
When sorting a tx list chronologically, it should by default take the finished timestamp.

sebasjm

2024-07-31 14:31

developer   ~0022881

first comment: agree completely
second comment: can we just add a `last_update_timestamp` and do not break the API? maybe we already have something like this


my comments: i think we should have something like

function getTransactionsV2(scopeInfo, filter?, pagination?)

 * The only mandatory field should be ScopeInfo since it doesn't make sense to mix currency IMHO

-----------

type pagination {
  offset: TransactionId
  limit: number
  order: "asc" | "desc"
  criteria: "update" | "amount" | ...
}

The reason for the names in the attributes is to stay consistent with other APIs https://bugs.gnunet.org/view.php?id=7949
 1 names are always use `offset` and `limit`
 2 `offset` is always the row id or element id (in this case transactionId)
 3 `order` is specified as a parameter, not in the limit parameter as a hyphen

We can have only 1 criteria, but this make it easy to add more later without breaking API.

-----------

type filter {
 search: RegexString
 status: Array<TransactionMajorState>;
}

we can add more filters later but this should be fine

MarcS

2024-07-31 17:56

developer   ~0022885

Well, since the result array of getTransactionsV2 consists of new structs (smaller, only basic info, pretty much the "common" part of the full transactions), we don't break anything if we rename "timestamp" to "created" there.
And since we need to add a second timestamp, the generic name "timestamp" is no longer appropriate.
"created" and "finished" are good names for the two timestamps - "last_update_timestamp" is ugly and way longer than needed!
Do we really need a third timestamp named "updated"? What for?

If we use a transactionID for offset (instead of index / UInt32), then "nil" or "" (empty string) should be the start or the end of the list, depending on the order. If order == "asc" then the oldest tx comes first, if order == "desc" or is missing, the the newest tx comes first.
Example: To get the most recent 3 transactions, you would specify `offset: nil, limit: 3, order: desc`. To get the very first 5: `offset: nil, limit: 5, order: asc`.

sebasjm

2024-07-31 19:31

developer   ~0022892

> the result array of getTransactionsV2 consists of new structs

I didn't thought we were discussing the result, just the input interface... @fdold?

Let's make sure we have the interface define before getting into it, @marc do you have a suggestion?

MarcS

2024-09-27 13:42

developer   ~0023382

Suggestion for filterByState:

enum TransactionStateFilter: String, Codable {
    case done
    case final // done, aborted, expired, ...
    case nonfinal // pending, dialog, suspended, aborting
}
done is needed for the sparklines (red and green bars in the section header - only tx which did change the balance).
final is needed for the main transaction list (and the Recent Transactions section in Balances). Might include refresh tx in debug mode.
nonfinal is needed for the pending transaction list.

Florian Dold

2024-10-02 17:06

manager   ~0023424

commit d7d8dee0f6c07b20ec1f1d481a0505f7c87a4055 (HEAD -> master, origin/master, origin/HEAD)
Author: Florian Dold <florian@dold.me>
Date: Wed Oct 2 17:04:42 2024 +0200

    harness: test for new getTransactionsV2 request

commit 761e65b5a1da6fc694f8beb1c5784631a9dd545b
Author: Florian Dold <florian@dold.me>
Date: Wed Oct 2 16:57:20 2024 +0200

    wallet-core: implement getTransactionsV2

Issue History

Date Modified Username Field Change
2024-07-30 22:22 Florian Dold New Issue
2024-07-30 22:22 Florian Dold Status new => assigned
2024-07-30 22:22 Florian Dold Assigned To => Florian Dold
2024-07-30 22:22 Florian Dold Summary implement getTransactionsV2 API based on materialized transactions => implement getTransactionsV2 API based on materialized transactions [design-required]
2024-07-30 23:45 MarcS Note Added: 0022872
2024-07-31 07:32 MarcS Note Added: 0022875
2024-07-31 14:31 sebasjm Note Added: 0022881
2024-07-31 17:56 MarcS Note Added: 0022885
2024-07-31 19:31 sebasjm Note Added: 0022892
2024-08-02 09:10 MarcS Relationship added related to 0006588
2024-09-27 13:42 MarcS Note Added: 0023382
2024-10-02 17:06 Florian Dold Status assigned => resolved
2024-10-02 17:06 Florian Dold Resolution open => fixed
2024-10-02 17:06 Florian Dold Note Added: 0023424
2024-10-02 17:37 Florian Dold Summary implement getTransactionsV2 API based on materialized transactions [design-required] => implement getTransactionsV2 API based on materialized transactions