♟ inka

[lib] Delete users for whom identity didnt return a device list for a long time

[lib] Handle identity timeout when fetching device lists

[lib] Reduce removePeerUsersActionType in thread reducer

[lib] Update usages of userHasDeviceList to acknowledge accountMissingStatus

[lib] Reduce users missing from identity

[lib] Mark missing users when fetching device lists

[lib] Add accountMissingStatus

Rebase, address review

Remove changes to useUsersSupportThickThreads

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.

[native] Fix NUX Android problem

Move callbacks out of components

Address review. Going to try biding the methods now

Please address Ashoat's comments before landing

[native] Fix styling in animation code

To verify that this formatting is correct we could consider deleting ignore and worker directives, auto-formatting the code, and reintroducing the directives.

Why do we expect to have multiple private chats, or multiple personal chats with one user? It's it impossible?

[native] Fix crash in NUX

[lib] Update useAncestorThreads to consider thick threads

[web][native] Update UI to not display GENESIS over thick threads

[lib][web][native] Refactor usingOlmViaTunnelbrokerForDMs

[lib] update threadLabel to handle thick threads

Update search header in chat creation on native not to show GENESIS for thick…

Remove unecessary memos

Rebase, fix determining whether thread is thick

[web][native] Show relationship prompt in thick PERSONAL threads

[lib] Update existingThreadInfoFinder to handle thick threads

[lib] Fix sendnig create_sidebar to peers

[lib][native] Review usingOlmViaTunnelbrokerForDMs and pendingThreadType

[lib][web][native] Update createPendingThread usages

[lib][web][native] Update createRealThreadFromPendingThread to handle thick…

[lib] Add useNewThickThread

[lib] Fix read only in thread-types

Without this diff, problem from ENG-9187 is not resolved. However

This diff introduces a different problem - if the component which calls this hook is unmounted before the effect is run, the operation is lost
We are changing the approach to generating DM ops (D13290), and @kamil will be landing code rendering this diff unnecessary - most likely tomorrow

@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

inka (Inka Sokołowska)
User

Projects

User Details

Recent Activity
View All

Oct 21 2024

Oct 18 2024

Oct 17 2024

Oct 16 2024

Oct 14 2024

Oct 11 2024

Oct 10 2024

Oct 8 2024

Oct 4 2024

Oct 3 2024

Oct 1 2024

Sep 30 2024

Sep 13 2024

Sep 12 2024

inka (Inka Sokołowska)User