Note to reviewers: this is addressing an Urgent issue, so would be great to prioritize!

(My comments are all repeats of my previous review)

I can change it either way, but we should decide whether we possibly want to use this table for calendar entires in the future. The benefit of using the same table for messages and entries is that if we fetch them by for example time, we will get them sorted correctly right away, and won't have to think about how many of each we should fetch

Can you clarify in what scenarios the id can be null? Usually we only see that for types that also have localID

Naming question

The test plan is D7114, but that diff failed the Android build. Can you fix it up so that the Android build is no longer breaking? I'm also curious how you were able to test the Android build... was it succeeding in your environment despite failing in CI?

Test

I'm not sure, but I think we should bump buildToolsVersion as well

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!

Almost there!

Looks good, but a couple notes in message-creator.js

Can you create a Linear task for handling this edge case and set it to Backlog?

Putting it in scripts/ sounds like a good idea to me!

I'm confused – we're just deleting this? Can you provide more details on what it was supposed to do, and how that intent is handled now?

Dependencies look good! No context on Rust unfortunately

I'm thinking basically:

Rebase

Rebase

Update to 0.0.2... it doesn't actually affect web or keyserver, but I figure it's better to do it

Pulled out native side to D7091 since it turned out to be more work than expected

Pull out the native work

I handled my first comment in D7089, and added tests in D7090. I also updated this diff to include the libdef in keyserver

RE CI failure, looks like we need to update the xcode folder in the fork as well. Will publish this for review for now, but will definitely make sure to fix the xcode folder before landing

Add keyserver types as well

Did you decrease both chat bubbles' sizes by avatarOffset? That means we're subtracting 2 * avatarOffset when we only need space for avatarOffset, right? Can you please adjust it appropriately to maintain previous proportions?

Offline asked @ginsu if we should maintain consistency on the width of chat message bubbles for viewer vs. non-viewer, he's going to check with Ted

@anunay also talked about adding some JS tests, but we can sequence that later

We'll also need to update:

Open to decreasing media width

Seems uncontroversial

Thanks!! Can you send that over to Ted on the design team to make sure he approves of the changes to FailedSend? (It's worth mentioning to Ted that it's not possible for both FailedSend and the edited label to appear at the same time.)

Hmm, not sure if that's an issue or not. I think it might be best to try using things like paddingLeft / marginLeft instead of left and position: 'absolute'... worried that border miscalculations can lead to issues, but not immediately sure what sort of concrete issues

Should I decrease the width of the inner message (the chat bubble that is sticking out), or should we increase the width of the message box of the composed message (currently has the red border around it)? I personally think there is still enough space on the right side to just increase the width of the message box, but if we think it would be better to decrease the width of the inner message to fit inside the message box lmk

In D6993#209859, @tomek wrote:

Do we know how this diff corresponds to https://linear.app/comm/issue/ENG-3322/fix-stale-cache-error-for-olmwasm#comment-d1aabe3d? Maybe this will somehow improve the experience about the path's configuration?

Why hasn't this been landed? As mentioned on Monday, we need to create a release with these changes ASAP so we can test the before the end of the month...

Why hasn't this been landed? It's an urgent issue and the diff was accepted on Monday...

FYI @kamil, another thing we'll need to move to SQLite

Will this potentially affect the width of the chat bubbles? Have you made sure that that the height measurement code is still working correctly?

Can you share an updated screenshot?