Switch from the prototype of duplicating the SQL filter as a runtime
and keeping them in sync on each event that might invalidate the current
filtered entries to a simpler approach of requesting the filter again
and doing the diff to detect the new changes.
Also add a new reset API to model the new entries design requirements.
The new approach shows less corner-case to handle and follows one source
of truth concept making debugging and future maintenance easier.
Other changes
- Fix pending mocking to work with multiple calls
- Refactor tests to account for the new changes
Updates status-desktop #12120
This commit adds HighestRole & a list of permissions in order of
importance to the CheckPermissionToJoinResponse.
This simplify client code so that it doesn't need to be calculated on
the client.
Enables controlling order of messages in tests. Useful for deterministic
reproduction of out-of-order messages.
Required for: status-im/status-desktop#13387
The test was flaky because of re-receiving the message, which resulted
in multiple identical requestsToJoin being added to messengerResponse.
We should in general avoid using arrays in messengerResponse and prefer
maps for exactly this reason.
* fix(community_import): fix import getting stuck in case of error in msgs
Fixes#13438 and #13439
* fix(community_import): fixes a bug with the timestamp format
The importer didn't like `-` time zones like `-4`. Using the standard date format makes it work.
This commit fixes a few issues with communities encryption:
Key distribution was disconnected from the community description, this created a case where the key would arrive after the community description and that would result in the client thinking that it was kicked.
To overcome this, we added a message that signals the user that is kicked. Also, we distribute the key with the community description so that there's no more issues with timing.
This is a bit expensive for large communities, and it will require some further optimizations.
Key distribution is now also connected to the request to join response, so there are no timing issues.
Fixes an issue with key distribution (race condition) where the community would be modified before being compared, resulting in a comparison of two identical communities, which would result in no key being distributed. This commit only partially address the issue.
Closes#13139
Previously it was not possible to change the state of the Debug toggle.
This is because the code forced the setting the default value, ignoring
the database setup, hence always setting the DEBUG as LogLevel.
This PR adds :
- A RuntimeLogLevel to enable setting ephemeral loggig strategy on status-go
This commit:
- Updates the default networks list to include the Sepolia test network
- Updates the "LoginAccount" method to build and include the wallet config in the node config
---------
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
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: a61ef74184
Pull Request resolved: https://github.com/status-im/status-go/pull/4480
The reading of the amount for pending transactions was done in the same
way as for transfers table. However, the transfers table has a string
hex representation of the amount, while the pending transactions table
has a binary representation of the amount (*big.Int). This was
triggering the not int warning and value was missing.
Updates status-desktop #12120
In case both to/from addresses are present in the list we were using
the same logic as for transfers. However, this doesn't make sense given
that we can have only one entry in pending activity.
The following cases are still covered
- When the receiver is in addresses we get received
- When both receiver and sender are in the list will get sent
- When the sender is on the list we will get sent
Updates status-desktop #12120
Jonathan Rainville
Stefan
Igor Sirotin
Roman Volosovskyi
Andrea Maria Piana
Mikhail Rogachev
osmaczko
Michal Iskierko
Patryk Osmaczko
Icaro Motta
Mohamed Javid
Dario Gabriel Lipicar
Mohsen
Anthony Laibe
Ivan Belyakov
Godfrain Jacques
richΛrd