update

In D15518#425977, @tomek wrote:

Does that mean that non-Fargate logs would also go to the Fargate groups?
Do we plan to simplify the names after the migration?

Does that mean that non-Fargate logs would also go to the Fargate groups?
Do we plan to simplify the names after the migration?

Makes sense!

Tested the migration:

1. Registered an account with SQLite DB 58
2. Logged in on a secondary with the migration - the worker logs show that the migration 59 succeeded
3. Updated the primary - the migration 59 succeeded

In D15512#425879, @ashoat wrote:

D15516 fixes the issue I was referring to.

The only other question on this diff is whether it reintroduces FIDs that were previously missing and should have been picked up. I don't think we need senderContext, since there is already senderFid. Do we need mentions?

D15516 fixes the issue I was referring to.

Address review

In D15512#425866, @ashoat wrote:

Here's a failing unit test: https://linear.app/comm/issue/ENG-11509/messages-appear-as-if-from-wrong-user#comment-94575408

Here's a failing unit test: https://linear.app/comm/issue/ENG-11509/messages-appear-as-if-from-wrong-user#comment-94575408

We have an object that looks like this:

These buttons not having a loading status was a pet peeve of mine. Thanks for fixing!

Rebase

In D15512#425772, @ashoat wrote:

I am skeptical of this approach. The core issue is that our FID extraction breaks when unexpected object fields are encountered. What happens if Farcaster introducing a new object field? Won’t the same issue occur? I think we need to fix the core issue instead of reverting this. Let me know if I’m missing something.

rebase before landing

I am skeptical of this approach. The core issue is that our FID extraction breaks when unexpected object fields are encountered. What happens if Farcaster introducing a new object field? Won’t the same issue occur? I think we need to fix the core issue instead of reverting this. Let me know if I’m missing something.