On a recent trip through a CPU profile taken while Signal Desktop
churned through a large backlog of messages, it was clear that
console.log was a major source of time spent, primarily the sort
operation required after every new entry is added to the Backbone
collection. So, three different techniques to combat this:
1) Reduce the maximum number of entries in the collection from 5k to 2k
2) No more logging of add/update/remove queue in MessageReceiver
3) No more log entries in Message.handleDataMessage main codepath
FREEBIE
* Fetch all conversations on startup of app, not on inbox load
A recent change to fetch conversations less didn't take into account all
that can happen in the app without the inbox loaded. That only happens
when the window is shown, and messages can come in with the app in the
background. In that case, the conversation wouldn't have been loaded
from the database, but would be saved to the database anyway, losing
data.
This change fetches all conversations as soon as the the data store is
ready for a fetch. It also introduces failsafe throws to ensure that
synchronous ConversationController accesses don't happen until the
initial fetch is complete. A new getUnsafe() method was required to
account for some of the model setup that happens during that initial
conversation fetch.
Fixes#1428
FREEBIE
* Fix tests: ConversationController.load() required before get()
FREEBIE
* Fetch conversations once, clean up ConversationController API
Race conditions around re-fetching have caused some problems recently,
so this removes the need to re-fetch conversations. They are fetched
once or saved once, and that is it. All interaction goes through the
ConversationController, which is the central source of truth.
We have two rules for Conversations:
1. If a conversation is in the ConversationController it doesn't need
to be fetched, but its initial fetch/save might be in progress. You
can wait for that fetch/save with conversation.initialPromise.
2. If a conversation is not already in the ConversationController, it's
not yet in the database. It needs to be added to the
ConversationController and saved to the database.
FREEBIE
* Remove Conversation.fetch() call in Message.handleDataMessage()
FREEBIE
* ConversationController.API cleanup: Fix two missing spots
FREEBIE
If the key has changed, saveIdentity will archive sibling sessions, but not the
session for the device it was called on. Therefore we have to archive that one
by hand.
Also switch from saving the identity of an OutgoingIdentityKeyError to just
triggering a profile fetch, mostly for consistency, simplicity, and DRYness.
// FREEBIE
We also show more errors than we used to in the MessageDetail screen
to help make it clear what is happening, and why the user would need to
re-send.
FREEBIE
Check for early read receipts for an incoming messages *after*
processing the expireTimer on that message. Then we can set
expirationStartTime appropriately if an early receipt is found.
Closes#950
// FREEBIE
This reverts commit a768b94471.
d2ddfc7 was enough to fix#989. Removing unregistered members from the
group (as opposed to silently ignorning them) creates greater potential
for getting out of sync with the member lists on other devices.
// FREEBIE
Previously, updateNumbers would throw an Error, so the whole group
update was discarded.
Signal-Android handles this the same way in
GroupMessageProcessor.handleGroupUpdate().
Closes#1056
Don't set lastMessage, let it update itself as needed, such as when
first rendering a conversation list item, and when its messages are
sent, received, or destroyed.
