Page MenuHomePhabricator

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

Authored by ashoat on Nov 27 2023, 1:20 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 6, 6:11 PM
Unknown Object (File)
Wed, Nov 6, 7:17 AM
Unknown Object (File)
Thu, Oct 17, 11:50 AM
Unknown Object (File)
Thu, Oct 17, 11:50 AM
Unknown Object (File)
Thu, Oct 17, 11:49 AM
Unknown Object (File)
Thu, Oct 17, 11:49 AM
Unknown Object (File)
Sep 6 2024, 2:31 AM
Unknown Object (File)
Sep 6 2024, 2:31 AM
Subscribers

Details

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
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 24465
Build 210196: arc lint + arc unit

Event Timeline

ashoat created this revision.
marcin added inline comments.
native/push/push-handler.react.js
405

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.

This revision is now accepted and ready to land.Nov 27 2023, 4:42 AM