rebase before landing

rebase before landing

address comments + rebase before landing

rebase before landing

It's not clear why you turned this into an object. You don't seem to be using the keys below in joinHandlers, and that seems to be the only place you communitiesToAutoJoin. Why did you update this to an object?

rebase before landing

rebase before landing

update

update

update

address comments

Hmm... what did you think of my suggestion earlier?

What do you think about making sure this effect is only run once per app startup?

update

Messed something up when stashing + rebasing

address comments

update

update

address comments

rebase before landing

rebase before landing

rebase before landing

address comments + rebase before landing

Was writing inline comments explaining why fid && fid !== NO_FID_METADATA can be just fid

address comments

address comments

address comments

In D12683#359698, @ashoat wrote:

In D12683#359547, @ginsu wrote:

Don't we now need to consider NO_FID_METADATA in all places we fetch the FID? It seems like it would need to be checked at every place the FID is fetched.

In the linear task we said:

Don't prompt if the FID in Redux is null NONE

Based off this I was under the impression that we only want to keep NO_FID_METADATA something that is only in redux/sqlite and not in the identity service. By keeping NO_FID_METADATA only in redux/sqlite, we would re-show the farcaster prompt to the user if they ever logged out + logged back in on native, and my thinking was that this would act as another one time nudge to the user that they should connect their farcaster account to comm.

It seems like I may have misinterpreted this point. If I did I should be able to easily update this diff so that we also have NO_FID_METADATA stored in the identity service if the user decides not to connect their farcaster account

I think there's some confusion here. I'm not suggesting storing NO_FID_METADATA on identity.

Rather, I'm concerned that we don't have any updates to code that fetches/checks syncedMetadataNames.CURRENT_USER_FID here.

We are storing a new special value in that field, that should be treated equivalently to null/undefined. Don't we need to update the code that fetches/checks syncedMetadataNames.CURRENT_USER_FID so that it knows to treat this special value as null/undefined?

Let me know if I'm missing something!

Don't we now need to consider NO_FID_METADATA in all places we fetch the FID? It seems like it would need to be checked at every place the FID is fetched.

forgot to save/commit changes

address comments

update

If the network issue gets triggered by the keyserver connection status cycling, then we'll want to add some condition to eg. make sure it only runs once per app start / foreground event. If that's the case, please re-request review. Otherwise it looks good to land!

fix network call getting triggered when client disconnect with the keyserver socket

rebase before landing

rebase before landing

Making @ashoat blocking since this is a copy change diff

shouldSkipPushPermissionAlert should probably be updated - if I understand correctly this diff makes it impossible for totalAlerts to exceed 1, is that correct?

When do we want handleCurrentUserFID to run?

update