Skip to content

Commit 1f86483

Browse files
committed
fix(messaging, ios): reject notification registration after 10 seconds
Previously there were cases where notification registration requests would wait indefinitely for the choreography of "request registration from system", "wait for system to respond" completed. There are cases (specifically if you are missing permissions...) where this choreography will never complete. Now we have a delayed async task that waits (for 10 seconds currently) and if it runs and sees that the choreography wasn't complete it cleans up and rejects so you avoid infinite hangs See #7272
1 parent 1232e97 commit 1f86483

File tree

1 file changed

+28
-2
lines changed

1 file changed

+28
-2
lines changed

packages/messaging/ios/RNFBMessaging/RNFBMessagingModule.m

Lines changed: 28 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -303,8 +303,7 @@ - (NSDictionary *)constantsToExport {
303303
: (RCTPromiseRejectBlock)reject) {
304304
#if TARGET_IPHONE_SIMULATOR
305305
#if !TARGET_CPU_ARM64
306-
// Do the registration on this unsupported simulator, but don't set up to wait for a token that
307-
// won't arrive
306+
// Register on this unsupported simulator, but no waiting for a token that won't arrive
308307
[[UIApplication sharedApplication] registerForRemoteNotifications];
309308
resolve(@([RCTConvert BOOL:@(YES)]));
310309
return;
@@ -317,6 +316,7 @@ - (NSDictionary *)constantsToExport {
317316
if (@available(iOS 10.0, *)) {
318317
#pragma pop
319318
if ([UIApplication sharedApplication].isRegisteredForRemoteNotifications == YES) {
319+
DLog(@"RNFBMessaging registerForRemoteNotifications - already registered.");
320320
resolve(@([RCTConvert BOOL:@(YES)]));
321321
return;
322322
} else {
@@ -326,6 +326,32 @@ - (NSDictionary *)constantsToExport {
326326
// Apple docs recommend that registerForRemoteNotifications is always called on app start
327327
// regardless of current status
328328
dispatch_async(dispatch_get_main_queue(), ^{
329+
// Sometimes the registration never completes, which deserves separate attention in other
330+
// areas. This area should protect itself against hanging forever regardless. Just in case,
331+
// check in after a delay and cleanup if required
332+
dispatch_after(
333+
dispatch_time(DISPATCH_TIME_NOW, 10.0 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{
334+
if ([RNFBMessagingAppDelegate sharedInstance].registerPromiseResolver != nil) {
335+
// if we got here and resolve/reject are still set, unset, log failure, reject
336+
DLog(@"RNFBMessaging dispatch_after block: we appear to have timed out. Rejecting");
337+
[[RNFBMessagingAppDelegate sharedInstance] setPromiseResolve:nil
338+
andPromiseReject:nil];
339+
340+
[RNFBSharedUtils
341+
rejectPromiseWithUserInfo:reject
342+
userInfo:[@{
343+
@"code" : @"unknown-error",
344+
@"message" :
345+
@"registerDeviceForRemoteMessages requested but "
346+
@"system did not respond. Possibly missing permission."
347+
} mutableCopy]];
348+
return;
349+
} else {
350+
DLog(@"RNFBMessaging dispatch_after: registerDeviceForRemoteMessages handled.");
351+
return;
352+
}
353+
});
354+
329355
[[UIApplication sharedApplication] registerForRemoteNotifications];
330356
});
331357
}

0 commit comments

Comments
 (0)