[Flow202][native][skip-ci] [39/x] Fix type error in ensureAndroidPushNotifsEnabled
ClosedPublic
Actions

Authored by ashoat on Nov 27 2023, 1:20 AM.

Details

Reviewers

marcin
michal
tomek

Commits

rCOMM9f1b2e8c7802: [Flow202][native][skip-ci] [39/x] Fix type error in…

Summary

Flow identified a legitimate type error here. When we find we don't have Android notif permissions, we ignore the result of requestAndroidNotificationsPermission. It seems like that would cause us to fail to register notif permissions on Android.

@marcin, can you confirm this interpretation?

NOTE: CI will fail on this diff. I considered the possibility of fixing Flow errors BEFORE upgrading Flow, but it wasn't possible... in some cases, the fixes to support the new version of Flow caused errors in the old version. I could have hidden these type errors with $FlowFixMe lines and then later revert those, but that seemed like too much busy work.

Depends on D10022

Test Plan

Confirm the Flow errors go away

Diff Detail

Repository

rCOMM Comm

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

ashoat requested review of this revision.Nov 27 2023, 1:20 AM

ashoat created this revision.

Harbormaster completed remote builds in B24465: Diff 33668.Nov 27 2023, 1:20 AM

ashoat added a child revision: D10024: [Flow202][native][skip-ci] [40/x] Fix type error in addManagePinsThreadPermissionToUser.Nov 27 2023, 1:21 AM

marcin accepted this revision.Nov 27 2023, 4:42 AM

marcin added inline comments.

native/push/push-handler.react.js
405 ↗	(On Diff #33668)	We definitely should return something from this lambda since otherwise it is useless to assign it to variable. When we find we don't have Android notif permissions, we ignore the result of requestAndroidNotificationsPermission. It seems like that would cause us to fail to register notif permissions on Android. If we find that we don't have permissions then just calling `await this.requestAndroidNotificationsPermission();` would result in a prompt asking for notifications permissions. However if the user grants those permissions then `hasPermissions` is still falsy (since promise returned nothing), so `deviceToken` will be set to null. Nevertheless permissions are actually granted byt the OS, so the state on the device and keyserver would heal itself on next render. This differential fixes this case so that if user grants permissions correct state is achieved immediately without need for additional re-render to heal the state.