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
BridgeMessage is a type of chat message content which will be sent from Matterbridge.
It contains fields:
- bridge name - depends on the used bridge, eg. "discord", "slack", etc...
- user name - username the message was received from
- content - message content
- user avatar
- message id
- parent message id - used in case of replies
Message is saved to a separated table: bridge_messages, similarly to discord messages.
The user_messages table is untouched.
bridge_messages table contains user_messages_id in order to join with user_messages table.
Issue #13098
keep restarting on error non-stop, removed some tests accordingly.
Fixed a flaky test for loadBlocksAndTransfers command.
Added tests for async.AtomicGroup.
Made tranfersCommand FiniteCommandWithErrorCounter to prevent infinite
restart.
This PR fixes [9947](status-im/status-desktop#9947) and contains :
- Commit to fix the changing of custom picture and having the change
reflected on contact's side
- Commit to fix the deleting of picture and having the change reflected
on contact's side
- Rename confusing `ImageType` to `ImageFormat`
This commit adds basic syncing capabilities with peers if they are both
online.
It updates the work done on MVDS, but I decided to create the code in
status-go instead, since it's very tight to the application (similarly
the code that was the inspiration for mvds, bramble, is all tight
together at the database level).
I reused parts of the protobufs.
The flow is:
1) An OFFER message is sent periodically with a bunch of message-ids and
group-ids.
2) Anyone can REQUEST some of those messages if not present in their
database.
3) The peer will then send over those messages.
It's disabled by default, but I am planning to add a way to set up the
flags.
Changes done in this commit solve the " The process cannot access the file because it is being used by another process." error
which was noticeable on Windows while migrating a profile keypair to a Keycard.