mirror of https://github.com/status-im/status-go.git synced 2025-01-09 06:12:55 +00:00

Stefan 812910f087 feat(wallet): Add session-based activity API for dynamic updates

This commit introduces the first steps towards implementing a session-based activity API to support dynamic updates of the current visualized filter in the wallet activity service. This change is necessary to move away from static paginated filtering, which was previously done in SQL, to a more dynamic approach that can handle updates in real-time.

The main changes include:
- Add basic `EventActivitySessionUpdated` support for pending transactions.
- Added a `TODO.md` file outlining the plan and requirements for dynamic activity updates.
- New session-related API to the `activity.Service`
- `session.go` contains the logic for session management and event processing related to activity updates.
- Add test case for incremental filter updates.

The commit also includes:

- various other minor changes and refactoring to support the new session-based approach.
- Deprecation notices added to the `api.go` file for methods that are no longer used by the status-desktop application.
- Clarification comments added to the `scheduler.go` file regarding replacement policies.

Updates: #12120

ghstack-source-id: a61ef74184bbf826a748a3b8e6934a08a1c4bd86
Pull Request resolved: https://github.com/status-im/status-go/pull/4480

2024-02-01 19:55:06 +01:00

3.7 KiB

Raw Blame History

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