Due to an old bug that has since be fixed, old history dbs can contain both a
Tox ID version and Tox public key version of the same friend, and always
themselves. They could have n more duplicates if they've updated their nospam.
Tox ID is an invalid length to be stored in strongly typed ToxPk, and in
general having multiple entries belonging to the same user effectively violates
our UNIQUE constraint on public_key.
Introduced in 7168d2b858Fix#6485
* Resolves#6221
* System message schema designed to take enum of message base + args
* New table layout required many updates to the queries executed by
history
* Bonus reduction of history signals/slots by issuing some file transfer
insertions directly when possible
* Added new negotiating friend state to allow delayed sending of offline
messages
* Added ability to flag currently outgoing message as broken in UI
* Reworked OfflineMsgEngine to support multiple receipt types
* Moved resending logic out of the OfflineMsgEngine
* Moved coordination of receipt and DispatchedMessageId into helper
class usable for both ExtensionReceiptNum and ReceiptNum
* Resending logic now has a failure case when the friend's extension
set is lower than the required extensions needed for the message
* When a user is known to be offline we do not allow use of any
extensions
* Added DB support for broken message reasons
* Added DB support to tie an faux_offline_pending message to a required
extension set
indexes need to be created after their corresponding table is created.
QMap doesn't enforce insertion order, just key order, so use a vector.
Also verify indexes from sql_master instead of only tables.
Before a bug in qTox would make it possible for a user to try to send an empty
action type message. This would fail to send at toxcore, but still be persisted
in history, causing it to fail every time FauxOfflineEngine tried to resend
it. Moving these stuck messages into the broke_messages table will stop qTox
from attempting to deliver them on each connect, and display in the GUI to
users that the messages aren't really pending anymore.
Fix#5776
Due to a long standing bug, faux offline message have been able to become stuck
going back years. Because of recent fixes to history loading, faux offline
messages will correctly all be sent on connection, but this causes an issue of
long stuck messages suddenly being delivered to a friend, out of context,
creating a confusing interaction. To work around this, this upgrade moves any
faux offline messages in a chat that are older than the last successfully
delivered message, indicating they were stuck, to a new table,
`broken_messages`, preventing them from ever being sent in the future.
This allows upgrade steps to query the db at the last version and run C++ code
on the results, then do a single transaction to make the upgrade, instead of
all actions of each upgrade step being required to be part of the overall
upgrade transaction.
Anthony Bilinski
Mick Sayson