PushSharp — несколько недопустимых токенов не вызывают делегатов ответа

Хотя я не изучал код PushSharp, я реализовал сервер, который взаимодействует с сервером APNS, поэтому могу назвать несколько возможных причин такого поведения.

Когда сервер Apple APNS обнаруживает недопустимый токен устройства (или любой другой тип недопустимых данных, например, слишком длинную полезную нагрузку), он записывает ответ об ошибке в сокет и закрывает соединение.

Теперь, если вы попытаетесь отправить 10 уведомлений и только после 10-го сообщения вы получите ответ об ошибке (через OnNotificationFailed в вашем случае), в котором говорится, что 5-е сообщение не удалось, это означает, что Apple никогда не обрабатывала сообщения с 6 по 10 (так что, если вы ожидали OnNotificationFailed срабатывать для некоторых из них, поэтому этого не произошло). Эти сообщения должны быть повторно отправлены. Я не знаю, обрабатывает ли PushSharp эту повторную отправку автоматически или вам нужно сделать это самостоятельно.

В дополнение к этому усложнению, в некоторых случаях (по крайней мере, когда я экспериментировал с недопустимыми токенами) вы (или PushSharp в вашем случае) могли не прочитать ответ об ошибке от Apple, и в этом случае вы только заметите, что что-то не так, когда соединение закрывается (т.е. вы получите ошибку при попытке отправить сообщение). В этом случае вам нужно открыть новый сокет, но вы понятия не имеете, какое сообщение вызвало сбой и какие сообщения следует отправить повторно.

Я предлагаю вам использовать только действительные токены устройств и сделать все возможное, чтобы ваша БД не содержала недействительных токенов, поскольку может быть сложно обрабатывать ответы об ошибках и закрытия соединений, вызванные такими токенами.