There is a tiny chance that without this fix some users which had message
duplicates because of issues with `message-id` calculation **BEFORE** `0.9.31`
still have duplicates in their DB and migrations will not pass without
this change. It only checks if the message with a new `message-id` has been
added and removes duplicate. The same way it removes duplicates from
`user-status` entity.
Currently, we calculate `message-id` as `sha3(from + raw_payload)`,
but we do not store `raw_payload` and it might be problematic
to restore it from DB because:
1) `content` field might be changed and so `Message` record
will differ from the original one
2) it is even more problematic for `GroupMembershipUpdate`
message because we don't save it in DB
In order to handle this, we can store `sha3(raw_payload)` as `raw-payload-hash`
prop of `message` entity and use it in case of emergency :)
`message-id` will be calculated as `sha3(from + sha3(raw_payload))`
Implementation:
1. `transport.utils/message-id` function is called only in three places now
and accepts `from` and `raw_payload` as parameters.
ID is calculated as `sha3(from + raw_payload)`.
2. This means that for wrapped private group chat message
the raw payload of `GroupMembershipUpdate` is used.
Issue was caused by https://github.com/status-im/status-react/pull/6722
Implementation:
1. `old-message-id` field (indexed) was introduced in `message` entity
and is calculated as `message-id` was calculated in `0.9.31`
```clojure
(defn old-message-id
[message]
(sha3 (pr-str message)))
```
2. When a reply message is sent from the PR version of app both `response-to`
and `response-to-v2` fields are sent as a part of `message`'s `content`
field, so that it can be recognized by `0.9.31`.
3. When PR version of app receives reply from `0.9.31` we check whether
message's `content` contains `response-to` but doesn't contain
`response-to-v2`, and if so we check whether DB contains message with
`old-message-id=response-to`. If such message has been found we assoc
`response-to-v2` to content.
4. If message from DB contains only `response-to` but not `response-to-v2`
attempt to fetch the message by `old-message-id` is done.
We add syncing of account fields in pairing messages (only photo-path &
name for now). Also a sync message is sent each time we send a
contact-update, to keep other devices in sync. The change is compatible
with previous clients as it's just an accretion of transit.
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Migration failures are handled separately from other errors which might appear
during opening account's realm DB. In case if user chooses to erase
the account's database, only this database will be removed and other accounts
will not be touched.
Previously we were only checking whether `network-status` is equal to
`:offline`, therefore allowing the user to send messages even when no
peers are connected (i.e. the app is displaying Connecting to peers..).
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Before we fetched ALL user-statuses with `status=received` (which means that
a message hasn't been seen), iterated them, grouped by chat and then stored
`message-ids` of these `user-statuses` in chat's `:unviewed-messages` key.
This commit introduces :unviewed-messages-count field in chat entity.
That means that there is no need to iterate `user-statuses` in order to count
a total number of unviewed messages, it is always stored along with chat.
In the rest of it, the difference is only that chat's db record should be
updated each time when unviewed messages are seen.
Go blocks parse try catch blocks and turn them into event
dispatches. This captures the original intent of the code to catch
errors and terminate the current async worker execution.
Signed-off-by: yenda <eric@status.im>
Andrey Shovkoplyas
Roman Volosovskyi
Dmitry
Vitaliy Vlasov
Maxim Tolochko
jeluard
Andrea Maria Piana
tbenr
Rob Culliton
Igor Mandrigin
Frederik Bolding
yenda
Bruce Hauman