fail permission check if we fail to fetch community root
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 8 2024
partially address feedback (add comment explaining nullish coalescing w threadID)
rebase before landing
rebase before landing
Looks like threadSettingsNotificationsCopy has already been updated
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.
Similar to D12676, I'd encourage reviewing this one carefully
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!
Worried that once !shouldCheckCurrentFIDRef.current, we'll be executing lines 171 and on, even after our FID is already set locally
Solution to community root issue looks good! Passing back to figure out what to do if communityMembersToRole isn't present. Might be worth also considering a scenario where it's present, but there is no m.id key
We should be really careful in reviewing this diff. It seems complex, and notif storage in C++ has historically been an area where we've often introduced very serious issues
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?
Rename onUnknownErrorAlertAcknowledged to onOtherErrorAlertAcknowledged
In D12679#359225, @tomek wrote:one try per startup
Why do we want to do this only once? Is there a downside to setting loginAttemptedRef.current to false after the login is done?
In D12678#359222, @tomek wrote:we're already auth'd with the authoritative keyserver
Why is it guaranteed?
Squash
Extract a function
shouldSkipPushPermissionAlert should probably be updated - if I understand correctly this diff makes it impossible for totalAlerts to exceed 1, is that correct?
set to false initially
Thank you for fixing this!
one try per startup
Why do we want to do this only once? Is there a downside to setting loginAttemptedRef.current to false after the login is done?
we're already auth'd with the authoritative keyserver
Why is it guaranteed?
When do we want handleCurrentUserFID to run?
update communityMembersToRole within for loop to fallback to threadID if threadInfo.community is null (which means it's a community root itself).
construct communityRootMembersToRole with both threadInfos and communityThreadInfos to handle scenario described here: https://phab.comm.dev/D12543?id=41737#inline-73658 where community root is one of the threadIDs passed into checkThreadsFrozen.
update
Jul 7 2024
rebase before landing
address simple communityRootThread -> communityRootThreadID rename feedback
address comments
We ended up going with a very different approach from this stack. Abandoning to tidy things up.
We ended up going with a very different approach from this stack. Abandoning to tidy things up.
We ended up going with a very different approach from this stack. Abandoning to tidy things up.
We ended up going with a very different approach from this stack. Abandoning to tidy things up.
We ended up going with a very different approach from this stack. Abandoning to tidy things up.