103 lines
3.7 KiB
Markdown
103 lines
3.7 KiB
Markdown
# Provide dynamic activity updates
|
|
|
|
Task: https://github.com/status-im/status-desktop/issues/12120
|
|
|
|
## Intro
|
|
|
|
In the current approach only static paginated filtering is possible because the filtering is done in SQL
|
|
|
|
The updated requirements need to support dynamic updates of the current visualized filter
|
|
|
|
## Plan
|
|
|
|
- [ ] Required common (runtime/SQL) infrastructure
|
|
- [-] Refactor into a session based filter
|
|
- [-] Keep a mirror of identities for session
|
|
- [-] Capture events (new downloaded and pending first)
|
|
- [-] Have the simplest filter to handle new and updated and emit wallet event
|
|
- [ ] Handle update filter events in UX and alter the model (add/remove)
|
|
- [ ] Asses how the runtime filter grows in complexity/risk
|
|
- [ ] Quick prototype of SQL only filter if still make sense
|
|
- [ ] Refactor the async handling to fit the session based better (use channels and goroutine)
|
|
|
|
## How to
|
|
|
|
I see two ways:
|
|
|
|
- Keep a **runtime** (go/nim) dynamic in memory filter that is in sync with the SQL filter and use the filter to process transactions updates and propagate to the current visualized model
|
|
- The filter will push changes to the in memory model based on the sorting and filtering criteria
|
|
- If the filter is completely in sync withe the SQL one, then the dynamic updates to the model should have the same content as fetched from scratch from the DB
|
|
- *Advantages*
|
|
- Less memory and performance requirements
|
|
- *Disadvantages*
|
|
- Two sources of truth for the filter
|
|
- With tests for each event this can be mitigated
|
|
- Complexity around the multi-transaction/sub-transaction relation
|
|
- If we miss doing equivalent changes in bot filters (SQL and runtime) the filter might not be in sync with the SQL one and have errors in update
|
|
- **Refresh SQL filter** on every transaction (or bulk) update to DB and compare with the current visualized filter to extract differences and push as change notifications
|
|
- This approach is more expensive in terms of memory and performance but will use only one source of truth implementation
|
|
- This way we know for sure that the updated model is in sync with a newly fetched one
|
|
- *Advantages*
|
|
- Less complexity and less risk to be out of sync with the SQL filter
|
|
- *Disadvantages*
|
|
- More memory and performance requirements
|
|
- The real improvement will be to do the postponed refactoring of the activity in DB
|
|
|
|
## Requirements
|
|
|
|
Expected filter states to be addressed
|
|
|
|
- Filter is set
|
|
- No Filter
|
|
- Filter is cleared
|
|
- How about if only partially cleared?
|
|
|
|
Expected dynamic events
|
|
|
|
- **New transactions**
|
|
- Pending
|
|
- Downloaded (external)
|
|
- Multi-transactions?
|
|
- **Transaction changed state**
|
|
- Pending to confirmed (new transaction/removed transaction)
|
|
|
|
Filter criteria
|
|
|
|
- time interval: start-end
|
|
- activity type (send/receive/buy/swap/bridge/contract_deploy/mint)
|
|
- status (pending/failed/confirmed/finalized)
|
|
- addresses
|
|
- tokens
|
|
- multi-transaction filtering transaction
|
|
|
|
## Implementation
|
|
|
|
### SQL filter
|
|
|
|
For new events
|
|
|
|
- keep a mirror of identities on status-go side (optional session based)
|
|
- on update events fetch identities and check against the mirror if any is new
|
|
- for new entries send the notification with the transaction details
|
|
- keep pending changes (not added)
|
|
- remove entries that were processed for this session
|
|
|
|
For update?
|
|
|
|
- check if entry is in the mirror and propagate update event
|
|
|
|
### Mirror filter
|
|
|
|
For new events
|
|
|
|
- keep a mirror of identities
|
|
- on update events pass them through the filter and if they pass send updates
|
|
- the filter checks criteria and available mirror interval to dismiss from mirror
|
|
- sub-transactions challenge
|
|
- TODO
|
|
- token challenges
|
|
- TODO
|
|
|
|
For update?
|
|
|
|
- check if entry is in the mirror and propagate update event |