User Details
- User Since
- Jul 13 2022, 2:18 AM (120 w, 3 h)
Mon, Oct 21
Rebase, address review
Update payload type
Fri, Oct 18
Remove changed to useUsersSupportThickThreads
Thu, Oct 17
Rebase
Rebase
Device list can be empty for a registered user if they log out of all devices
Initially I modified useGetAndUpdateDeviceListsForUsers, but I realised that it is used in many places. Some of those places seem like we don't want to use this mechanism.
- In UserInfosHandler we want to request all missing device lists as the app starts. There is a special mechanism there to make sure we request them exactly once.
- In SecondaryDeviceQRCodeScanner we request current users device list, so it can never be empty as far as I understand.
- In usePeerToPeerMessageHandler we request the device list when we receive a DEVICE_LIST_UPDATED or IDENTITY_DEVICE_LIST_UPDATED. I feel like we really want to request the device list in this case, and ignore the timeout.
Wed, Oct 16
Mon, Oct 14
Move callbacks out of components
Address review. Going to try biding the methods now
Fri, Oct 11
Thu, Oct 10
Please address Ashoat's comments before landing
Tue, Oct 8
Fri, Oct 4
To verify that this formatting is correct we could consider deleting ignore and worker directives, auto-formatting the code, and reintroducing the directives.
Thu, Oct 3
Tue, Oct 1
Why do we expect to have multiple private chats, or multiple personal chats with one user? It's it impossible?
Mon, Sep 30
Sep 13 2024
Address review
Simplify
Remove unecessary memos
Rebase, fix determining whether thread is thick
Sep 12 2024
Without this diff, problem from ENG-9187 is not resolved. However
@marcin changed a different place than I had in mind, but this made me realise that we call threadTypeIsThick check on a result of pendingThreadType. So the outcome is determined by the flag we use in this pendingThreadType. We should create a proper childThreadType depending on whether we want thick or thin and then use it in ParentThreadHeader
Rebase
Address review
Address review