This commit fixes `native token not found` issue that occurs only when the input params
of an already successfully generated route for a fast chain (refers to a chain that generates
new block very fast, like optimism, arbitrum) are updated.
The reason of the issue was that active route remains the same until the resolving of a new route
for updated input parameters gets generated, for fast chains that was enough time to generate a new
block and send fees update for the previously active route. This commit fixes that possibility by
aborting updates in a better way.
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
If we use `:=` we always call it, but it's not necessary for most
targetrs. It requires `git` which is not available in Nix build sandbox.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
When adding an account via seed phrase, for a key pair that was previously deleted,
suggested path should start from index 0. It was not like that before, this commit fixes that.
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.
This commit simplifies the sending process of the best route suggested by the router.
It also makes the sending process the same for accounts (key pairs) migrated to a keycard
and those stored locally in local keystore files.
Deprecated endpoints:
- `CreateMultiTransaction`
- `ProceedWithTransactionsSignatures`
Deprecated signal:
- `wallet.sign.transactions`
New endpoints:
- `BuildTransactionsFromRoute`
- `SendRouterTransactionsWithSignatures`
The flow for sending the best router suggested by the router:
- call `BuildTransactionsFromRoute`
- wait for the `wallet.router.sign-transactions` signal
- sign received hashes using `SignMessage` call or sign on keycard
- call `SendRouterTransactionsWithSignatures` with the signatures of signed hashes from the previous step
- `wallet.router.transactions-sent` signal will be sent after transactions are sent or if an error occurs
New signals:
- `wallet.router.sending-transactions-started` // notifies client that the sending transactions process started
- `wallet.router.sign-transactions` // notifies client about the list of transactions that need to be signed
- `wallet.router.transactions-sent` // notifies client about transactions that are sent
- `wallet.transaction.status-changed` // notifies about status of sent transactions
Added props:
- `Version` used to differ old and new usage
- `ValueOut`
- `FromChainID`
- `ToChainID`
- `FromTokenID`
- `ToTokenID`
- `ToContractAddress`
- `SlippagePercentage`
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.