I think this is right, but would like @atul to confirm

Should we consider doing this as a SELECT ... UNION SELECT?

See my previous review

Please address inline comments before landing! If you feel strongly that the data types should not be read-only, can you please re-request review?

Can you explain a little bit why you opted against using createRecursiveDrawerItemsData? Assume this is what you meant when you said "Considered different approaches, but this seemed the cleanest", but would like a bit more context

Not clear why this is being prioritized right now when avatars work is so very deeply behind.

PS – a good way to introduce a use case for this "dangling function" would have been to refactor existing migrations to use it. In this case I'm aware of how it'll be used, but I still feel strongly that it's easier to review diffs that avoid this "dangling function" pattern

I don't think this is correct. You'll exclude pinnedCount if it's 0, whereas the keyserver always includes it, which will mean that there will be inconsistency

Marking prekey as published is expected to take place somewhere else in the code where it is sent to the keyserver.

I think we'll need to find a way to synchronize any updates to Olm accounts / sessions so that we only do one such update at a time

Address inline comment before landing, and please pay more attention to existing codebase conventions going forward

When I say something like this:

It was stated during crypto sync that marking as published takes place when prekey is sent to the identity service. It is out of the scope of this project to make a decision where, when and how prekey will be sent to the keyserver.

Please address my feedback before landing... repeating it from last review

Not clear why pickled_olm_session can be NULL... I think we should switch it to NOT NULL before landing

Not clear why pickling_key and pickled_olm_account can be NULL... I think we should switch them to NOT NULL before landing

I tried testing on Android 5.1 and got this fatal instead. I'm just going to land this... I think it's unlikely that these broken symlinks were doing anything good for any version of Android

Going to land this as-is to fix up master ahead of the week starting

Predictably, the test plan works with these files just deleted...

Thanks!! Proto change makes sense to me; resigning so others can take a look at the Rust

Thanks for explaining!

It works similarly to inlineEngagementLeftStyle and other styles in chat-constants.js, without adding it to height measurement

Great work!! This is significantly improved :)

Thank you!