Ensure that communities created prior to the introduction of tokenized
ownership propagate community ID through the description.
fixes: status-im/status-desktop#16226
* fix(sync)_: Improve EnableInstallationAndSync and add EnableInstallationV2
- Refactor EnableInstallationAndSync for better error handling and response merging
- Add new EnableInstallationV2 method returning the installation
- Update tests to check for installation in response
- Deprecate old EnableInstallation method
* chore_: remove EnableInstallationV2
* fix(sync)_: create/delete AC notification only when targetInstallationID match
- Add targetInstallationID parameter to SendPairInstallation function
- Update protobuf SyncPairInstallation struct with TargetInstallationId field
- Modify method calls across multiple test files to include new parameter
- Update pairing.proto and pairing.pb.go with new field for local pairing
* chore_: rename stubEnableInstallationAndPair
chore_: move InstallationIDProvider
chore_: revert endpoints.go
test_: check AC with resp
chore_: rename ModifiedInstallationsTargetedToThisDevice
test_: add InstallationIDProvider
chore_: revert endpoints.go
chore_: remove comment
test_: add TestNewInstallationCreatedIsNotDeleted
Syncing the entire community for potentially frequent actions like
`LastOpenedAt` updates is highly inefficient when using Waku as the
transport layer, as it can result in significant bandwidth overhead.
We remove the shared accounts to send normal admins to not leak the addresses, however, that was a destructive action that also removed them from the `requestToJoin` param, which is reused later in the code, so it created an unwanted side effect. The side effect is now erased.
Logs from `messenger_mailserver` occupy 40 out of 100MB of data in
my `geth.log`.
Instead of extending `logger` with many parameters, such as `chatIDs`,
`topic`, etc., the hash of those parameters is calucalted and kept as a
context.
iterates: #5889
Fixes https://github.com/status-im/status-desktop/issues/16323
The problem was that the code expected to receive the Discord message ID, but the bridge is smart enough to return the Status message ID already, so there is no need to try and convert it.
There were also a couple issues in the bridge code itself.
* feat_: log error and stacktrace when panic in goroutine
* test_: add test TestSafeGo
* chore_: rename logAndCall to call
* chore_: rename SafeGo to Go
* chore_: make lint-fix
* chore_: use t.Cleanup
* chore_: Revert "chore_: use t.Cleanup"
This reverts commit 4eb420d179cc0e208e84c13cb941e6b3d1ed9819.
* chore_: Revert "chore_: make lint-fix"
This reverts commit fcc995f157e671a4229b47419c3a0e4004b5fdab.
* chore_: Revert "chore_: rename SafeGo to Go"
This reverts commit a6d73d6df583f313032d79aac62f66328039cb55.
* chore_: Revert "chore_: rename logAndCall to call"
This reverts commit 8fbe993bedb9fbba67349a44f151e2dd5e3bc4cc.
* chore_: Revert "test_: add test TestSafeGo"
This reverts commit a1fa91839f3960398980c6bf456e6462ec944819.
* chore_: Revert "feat_: log error and stacktrace when panic in goroutine"
This reverts commit f612dd828fa2ce410d0e806fe773ecbe3e86a68a.
* feat_: log error and stacktrace when panic in goroutine
* chore_: make lint-fix
* chore_: rename logAndCall to call
* chore_: renaming LogOnPanic
* chore_: update rest goroutine function calls
* chore_: make lint-fix
* feat(sync)!: remove compatibility with v2.29
* feat(sync)_: add AC notifications when initiating the sync fallback
Needed for https://github.com/status-im/status-desktop/issues/15750
Adds an AC notification when the syncing fails and the user is prompted to use a seed phrase instead.
There is one notification for the initiator (created) and one for the old account (received).
Once the flow is completed, ie the receiver presses Enable and sync, the notifications are deleted
* test_: update test
* fix_: lint issue
* chore_: ignore tmp file generated by make lint-fix
* chore_: rename EnableAndSyncInstallation to EnableInstallationAndSync
* chore_: address review feedback
* chore_: revert changes to .gitignore
* fix_: simplify code
* fix_: keep old API
---------
Co-authored-by: Jonathan Rainville <rainville.jonathan@gmail.com>
This commit fixes the flaky TestBackupKeypairs test.
The flakiness is due to the order in which the backup is processed. The test expects the profile keypair addresses first but sometimes, the non-profile keypair is processed before the profile keypair. This commit updates the test to ensure the received addresses exist in the expected.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
* feat_: accept community join request with mvds
* chore_: no sender when use mvds in comm join response
* fix_: only use mvds for tokenized communities
* chore_: add comment for this.
This change attempts to resolve an issue with notifications being deleted for users after another user deletes the last message inside a community.
The cause of the issue seemed to be related to how notifications could reference a message with the `LastMessage` field. And if the last message was deleted from a community, then the notifications that reference the last message via `LastMessage` field would also removed/deleted.
Moving forward, we will no longer use the `LastMessage` field as a way to detect notifications that need to be deleted, and we now only use the `Message` field of a notification, and we have adapted the creation of notifications to avoid using the `LastMessage` field.
This commit moves the "accountsFeed" from "initServices" to the status node config, and adds a reference to messenger config for sending events on handling backed-up data.
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
- Introduce a constant `suggestionsLimit` set to 15
- Apply the suggestion limit when calculating mention suggestions
- Replace unlimited suggestions (-1) with the new limit in relevant function calls
- This change aims to improve performance and user experience by limiting the number of mention suggestions displayed
* feat_: request to join community message use mvds
* chore_: set skip encryption layer to false when request to join community
* chore_: fix tests.
* chore_: fix test.
* chore_: fix more tests
* chore_: fix resend raw message test.
* chore_: add comments for skip encryption layer
* fix(TestProfilingCPU)_: enable run with -count=2
* fix(TestProfilingMem)_: enable run with -count=2
* fix(zaputil)_: register encoder only once
* fix(timesource)_: global variables override in tests
* fix(TestClosingsqlDB)_: delete database from cache
* fix(postgres/helpers)_: drop connections before dropping database
* fix_: linter
* chore_: remove redundant condition
Fixes https://github.com/status-im/status-desktop/issues/15930
The issue happened because I received a notification about a contact request, but the request was not associated with a message in the DB. The DB didn't have a message with the required ID in it.
This potential fix moves the creation of the contact request later in the handling code, because the only way this bug can happen as far as I see it is if there is an error later in the handler function and the message is never added to the response, and therefore never saved.
Richard Ramos
Patryk Osmaczko
frank
Igor Sirotin
Jonathan Rainville
Mohamed Javid
kaichao
Alexandra Betouni
Azanul Haque
Sean Hagstrom
Arseniy Klempner
Parvesh Monu
Pablo Lopez
Andrea Maria Piana