Requesting review after unrelated CI failure

Fix optional chaining issues after Atul's review.
Remove duplicated part of code, that was not removed after moving some parts of the logic to the parent component.

Change check to threadIsPending

In D4435#125813, @ashoat wrote:

Do you think we can check threadIsPending instead? I think it's probably good that we unset the activeChatThreadID if it is non-pending but does not exist in threadInfos.

In D4071#118719, @ashoat wrote:

That's very strange... I haven't seen that sort of deadlock in the past when running migrations like this. I seem to recall we were getting some deadlocks due to nodemon – have you tried running this via yarn prod instead of yarn dev to confirm nodemon is not at fault?

In D4071#117511, @ashoat wrote:

How bad is the deadlock? dbQuery is set up to retry a query twice (for a total of 3 tries) if it sees a deadlock.

While performing last tests just before landing, I noticed, that it still sometimes happens (although less frequently than before) to deadlock database during the migration - in both dev and production modes. It seems to happen on different queries and is non-deterministic (I perform migration from the same database state from backup).

add condition to delay migrations only in dev mode

add delay before executing transaction to avoid restarting migration in dev environment

Process threads sorted by depth to avoid processing parent threads before children

change order in if statement

Seems to work correctly.

rebase

set node to null when updating menu symbol

re-run CI

re-run CI

re-run CI

re-run CI

re-run CI

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

add newline

add self closing tag & remove notificationSettings dependence from useMemo

fixes following review comments

update css class name

rename active to selected

rename property and add $ReadOnlyArray

rename active prop into valid and add self closing tag

In D3949#110692, @atul wrote:

Accepting, but it would be good to clarify the distinction between the different meanings of "active" in the NotificationsOption and NotificationsOptionInfo components... maybe using different words to make things clearer? Could make the changes where the names are introduced and rebase this stack... or just add a diff to the end of this stack.

---

It looks like the image in the diff description is from the Figma document?

Would be handy to see how the component looks as is (in a dummy modal with placeholder values or something?)

I feel like the test plan still hasn't been updated. Am I right?