-
-
Notifications
You must be signed in to change notification settings - Fork 666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
APNs: log invalid device tokens, rather than sending them #3888
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @ray-kraesig ! This should be helpful.
One style comment below.
src/notification/index.js
Outdated
// A device token should normally be a string of hex digits. Sometimes, | ||
// however, we appear to receive objects here. Log this. (See issue #3672.) | ||
if (typeof deviceToken === 'string' && deviceToken !== '[Object object]') { | ||
this.dispatch(gotPushToken(deviceToken)); | ||
await this.dispatch(sendAllPushToken()); | ||
} else { | ||
logging.error('Received non-string device token', { deviceToken }); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's write this error path in the early-return pattern:
if (isBad(thing)) {
logging.error('Thing is bad', { thing });
return;
}
processNormally(thing);
This keeps the code that handles each error next to the code that tests for it. A related effect is that it helps the reader to study the behavior in a given error case, or the behavior in the "normal"/happy case, or to understand the full behavior by divide-and-conquer.
Doesn't hugely matter for a function this short with just one error case. But it's good to have the pattern consistent for if the function grows, or if another contributor copies the pattern in another context. And even at this scale I think it already helps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I actually did write it that way in the first draft; I switched to the above because the negated logic seemed more straightforward.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool. Yeah, I think the main thing that can make this nested style appealing is that it lets you write down the things that are true in the happy path, rather than the things that aren't.
But then I think the effect on the code's overall structure generally ends up outweighing that, even at this scale.
Thanks for the revision!
cb11475
to
9d499d2
Compare
Done. Also, more honesty about being dishonest about types. |
APNs device tokens, as received through out iOS notifications library, should be a hex string. Unfortunately, they're sometimes being sent to the server as "[Object object]". This is most likely due to the argument of `handleDeviceToken` actually being an object, despite its typing as `string`, and being improperly stringified by `encodeParamsForUrl`. However, it may alternatively be the case that someone is mis-stringifying the object before we get our hands on it, so log that case too. This is work toward the resolution of zulip#3672.
9d499d2
to
d7b68bd
Compare
Thanks -- merged! |
When no registration token is available, Android may report a null token. This is has been observed to happen at least on an emulator without Google Play services, and is reported to happen on physical devices without GP, as well as on devices without Internet access. Accept null device tokens without comment, effectively returning to pre-zulip#3888 behavior for them. Adjust the types of `gotPushToken` _et al._, and the docstring of `pushToken`, to reflect this.
When no registration token is available, Android may report a null token. This is has been observed to happen at least on an emulator without Google Play services, and is reported to happen on physical devices without GP, as well as on devices without Internet access. Accept null device tokens without comment, effectively returning to pre-zulip#3888 behavior for them. Adjust the types of `gotPushToken` _et al._, and the docstring of `pushToken`, to reflect this.
When no registration token is available, Android may report a null token. This is has been observed to happen at least on an emulator without Google Play services, and is reported to happen on physical devices without GP, as well as on devices without Internet access. Accept null device tokens without comment, effectively returning to pre-zulip#3888 behavior for them. Adjust the types of `gotPushToken` _et al._, and the docstring of `pushToken`, to reflect this.
When no registration token is available, Android may report a null token. This is has been observed to happen at least on an emulator without Google Play services, and is reported to happen on physical devices without GP, as well as on devices without Internet access. Accept null device tokens without comment, effectively returning to pre-zulip#3888 behavior for them. Adjust the types of `gotPushToken` _et al._ and the docstring of `pushToken` to reflect this. Additionally, as issue zulip#3672 is resolved, we no longer need an explanatory comment pointing to it. Remove the now-confirmed- unnecessary check for the exact string `"[Object object]"`.
When no registration token is available, Android may report a null token. This is has been observed to happen at least on an emulator without Google Play services, and is reported to happen on physical devices without GP, as well as on devices without Internet access. Accept null device tokens without comment, effectively returning to pre-zulip#3888 behavior for them. Adjust the types of `gotPushToken` _et al._, and the docstring of `pushToken`, to reflect this.
When no registration token is available, Android may report a null token. This is has been observed to happen at least on an emulator without Google Play services, and is reported to happen on physical devices without GP, as well as on devices without Internet access. Accept null device tokens without comment, effectively returning to pre-d7b68bddc (zulip#3888) behavior for them. Adjust the types of `gotPushToken` _et al._, and the docstring of `pushToken`, to reflect this.
APNs device tokens, as received through out iOS notifications library,
should be a hex string. Unfortunately, they're sometimes being sent to
the server as "[Object object]".
This is most likely due to the argument of
handleDeviceToken
actually being an object, despite its typing as
string
, and beingimproperly stringified by
encodeParamsForUrl
. However, it mayalternatively be the case that someone is mis-stringifying the object
before we get ahold of it, so log that case too.
This is work toward the resolution of #3672.