Description
Subscriber deactivation is always a side effect of subscriber-error event received after unsucesfull message sending. It could not be initiated by a user himself.
Technical details
Since all subscriber errors are handled by the directory-responses service which is located on a slave cluster, the deactivation process starts from there and is being transferred to the main production cluster (amazon) within a sender-events-proxy service.
Events came from the slave cluster then are being handled by subscribers-errors service. If error we recieve is about device unregistering (DEVICE_UNREGISTERED for XMPP, 404 for FCM), the following steps are taken:
- attempt to refresh the token is being made
- if token is not recoverable after a few consecutive attempts, subscriber is being deactivated
Links
- coupled with: