Rename file, move processMessagesForSearch to postMessageSend

Rebase

Rebase

Address comments

Change type to inexact

Address review comments

Address comments

In D6965#212104, @ashoat wrote:

We can consider preventing users from sending empty edit messages.

We should do this. We don't allow empty messages for messageTypes.TEXT. Can you create a follow-up Linear task for this before landing?

In D7067#212617, @ashoat wrote:

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.)

Sorry for all the specific test plan requests, I just remember there being a lot of edge cases with this code from back when I was working on it.

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:

rebase and land

rebase and land

Rest of the comments were discussed on Comm

(Really great to see we're adding DB tests right off the bat)

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.