- removed timestamp parameter. This wasn't totally obvious, previously we were tracking two pieces of state
1. `unreadIndicator.firstUnseenTimestamp`:
the first unseen timestamp for a conversation that exists in the database
2. `unreadIndicator.timestamp`:
the timestamp of the first interaction *after* the unread indicator that fits in the loading window
We don't actually need to track `2` because it was only used in a comparison like:
viewItem.interaction.timestampForSorting >= unreadIndicator.timestamp
But by definition, unreadIndicator.firstUnseenTimestamp is always less than or
equal to unreadIndicator.timestamp. Put into terms of the `sortId` corallary,
the sortId of the first unseen interaction in the database is always less than
or equal to the sortId of the first unseen interaction that fits in the loading
window.
In other words, there's no situation where
viewItem.interaction.sortId >= unreadIndicator.firstUnseenSortId
We were often using `timestampForLegacySorting`, which is convoluted for when
we actually just want received time.
In some sense this is a superficial change, but it's part of auditing that
we've completed moved away from timestampForLegacySorting.
No change in functionality in this commit, I just broke the signature to have a
systematic audit of the callsites. Added TODO's with the plan for each call.
Historically we would backdate the SN change messages, but since adopting
non-blocking SN changes long ago, they're already sorted properly by creation
time, so backdating has been unnecessary for a while.
I also audited that all other error messages are saved directly after creation.
I applied deprecation attributes as appropriate as I audited.
Since we're no longer sorting by timestamp we have to ensure we save the update
info message before we save any affected message, e.g. in the case of implicit
updates.
There is no change in functionality in this commit.
Apart from clarifying what the timestamp means (it's the timestamp of the
*sender*), this intentionally breaks all the call sites, so I could have a sane
way to thoroughly audit wherever we're passing in timestamps, to see where
we're depending on them to affect sort order.
For the sake of a cleaner diff of meaningful changes, instead of "fixing"
everything in this commit, I've just added comments and renamed signatures.
WIP: migration / autoincrement logic
TODO:
-[x] contact offer
-[ ] verify all paths that utilized timestampForSorting, e.g. make sure SN appear before the message they affect, etc.
-[x] Monotonic ID
-[x] New extension which sorts by id
-[x] Migration
-[ ] batch migration?
fixup contact offers
TODO:
-[ ] contact offer
-[ ] verify all paths that utilized timestampForSorting, e.g. make sure SN appear before the message they affect, etc.
-[x] Monotonic ID
-[x] New extension which sorts by id
-[x] Migration
-[ ] batch migration?
