Passing back to you with question about multiple files being uploaded to the same endpoint at once. I don't think we actually ever do this, so I'm wondering if we can simply throw an exception if we get multiple files in the same upload

That makes sense RE older clients. Thinking about it more, I'm not actually sure why we ever thought it made sense to "hide" the avatar field from older clients... they're going to eventually need the field, and if we hide it from them initially then they will need to rely on the state check mechanism to fix things after they upgrade codeVersions.

The current fetchPinnedMessageInfos query doesn't have the ability to paginate, but it can always be added in later. We could initially fetch all of the pinned messages at once from the server, but have a task to paginate the fetching.

Yeah we can probably get rid of them, feel free to put up a diff

One last thing that would be great if you could test: what happens if you upload a single very "thin" photo? I want to make sure it doesn't expand to take the whole width and then becomes super tall. (Or at least, that there's no regression in this.)

Back to your queue for nits and fetchDerivedMessages

Adding @kuba here – he is looking at fetchDerivedMessages right now in D7141

Can you please amend the Test Plan to include:

Did not review this closely

I'm sorry, I completely missed that it was an old migration. My apologies for making assumptions and leaving an unnecessarily aggressive comment

On context on why this diff has been up for 2 weeks and hasn't been reviewed?

Note that I didn't bother adding a line here because @commapp/opaque-ke-wasm isn't actually consumed directly via Yarn workspaces, so we don't need its package.json in order to run yarn cleaninstall. Instead, we'll consume published versions of @commapp/opaque-ke-wasm as an NPM package.

The problem is that we would need to validate each query result manually, going through each column one-by-one and checking the result type. This isn’t something we do today for MySQL queries typically. If we feel strongly about doing input validation for SQL query results we could do with tcomb, but I’m not sure that the effort is worth it.

Just tested and it looks like this solves rendering SVG data URIs for us!! I haven't tested other types, but PNG, JPEG, and SVG are all listed as supported in the docs. Thanks @bartek for the tip! This is way better than what I had planned to do on Android.

Done testing!! I think this is safe to land. I haven't tested blurhash or SVG / data URI support yet, but those are things that react-native-fast-image can't handle today anyways

That general approach looks great!! Great work figuring this out.

We should not be polluting the global namespace in D7101. You should not be able to use QueryExecResult without importing it unless it's in the Flow lib.

We can consider preventing users from sending empty edit messages.

In D7094#211792, @michal wrote:

This diff seems to call getAPNsNotificationTopic with two parameters, but the version of that function in master only takes one parameter. Can you please update this diff's dependencies so I can see the rest of your stack? Please always set diff dependencies!

There's no stack for this diff, I'm calling getAPNsNotificationTopic with one argument, it's just an object with two fields.

Will this affect the height of the item? Have you made the necessary changes to the height determination code (textMessageItemHeight)?

You should definitely have included @inka on this review – she is by far the expert on this code

I am skeptical that you need to be touching entity-text.js or entity-helpers.js at all. Can you explain what updates you think you need to the EntityText framework and why?

Mostly questions

Just a question

Please update native/expo-modules/aes-crypto/android/build.gradle before landing!