parse-community
Status 400 and reason BadDeviceToken
I've updated the parse-server to the latest 2.5.3 version and parse-server-push-adapter v 2.0.0 and now my error logs are full of these messages:
3|parse-wr | node-pre-gyp
3|parse-wr |
3|parse-wr | ERR!
3|parse-wr |
3|parse-wr | parse-server-push-adapter APNS
3|parse-wr | APNS error transmitting to device 28c89bdc6a0e7a6454fb0cc446229a0841eecdea955533d3c549a658bb15fc98 with status 400 and reason BadDeviceToken
There are so many of them that I can't see anything else.
The questions are:
- How can I ignore these errors in my pm2 config file?
- Is there a way to remove bad device tokens automatically from Installation Collection?
How can I ignore these errors in my pm2 config file?
There is no particular way to ignore those, they are produced when running with VERBOSE
Is there a way to remove bad device tokens automatically from Installation Collection?
For now there isn't
Hey @flovilmart, my VERBOSE setting is disabled, but my logs are filled with these errors by 90%.
How do I turn them off? The fact that servers show and write these errors damage the performance.
After looking into the repo, the error is reported by the logger as an error log, you won’t be able to disable it at that time.
Hi @flovilmart, we are running our parse server with logLevel: 'none', but we are still getting these errors logged since we upgraded to 2.5.3, is this intended?
Looks like they just forgot to set the right setting for these errors.
I've downgraded to an earlier version.
Any news on this issue? Is there a way to switch the Push errors off?
Or is there a way to automatically erase all Installations with Bad Device Tokens?
As far as I know in the latest version there is a way to automatically delete bad tokens.
Do you know any adequate way to find the bad device tokens and erase them?
We have a bunch of them, and they only increase in numbers, especially the ones for Androids. They never self-delete even if the app is reinstalled.
Hi @funkenstrahlen can you please tell the way to automatically delete bad tokens? thanks a lot.
I have figured it out. After release 2.6.3, you can automatically delete bad tokens by setting the PARSE_SERVER_CLEANUP_INVALID_INSTALLATIONS environment variable = 1. I have tested it on 2.6.5 and pass.
Still thanks a lot to @funkenstrahlen for giving the hint.
@wicked-wei , our tests for this PARSE_SERVER_CLEANUP_INVALID_INSTALLATIONS option showed that:
- even the VALID iOS deviceTokens are erased for some reason
- the old, invalid, unused android deviceTokens are not erased at all
@halvini thanks for your comment. I haven't seen the problem you mentioned yet but I will keep eyes on it. And, the code that PARSE_SERVER_CLEANUP_INVALID_INSTALLATIONS option works is at parse-server/src/StatusHandler.js, you can check it out for more detail.
@halvini can you please point out what part of the logic there is not working as expected?
@flovilmart , the issue is described in this ticket: https://github.com/parse-community/Parse-SDK-iOS-OSX/issues/1224
We are 100% sure that PARSE_SERVER_CLEANUP_INVALID_INSTALLATIONS flag cleans up even VALID ios installations. Why? I don't know. I've checked the StatusHandler, I've checked the APNS.js. I don't see anything unusual out there, but I believe that when you send many many push notifications to different installations, probably APNS returns BadDeviceToken error even for valid installations. It doesn't happen immediately. For instance, my own valid installation was unset by this flag in a week after I turned it on. So, probably, if there is a timeout, or any other connection or delivery error, the APNS thinks that device is either Unregistered, or Bad.
@halvini you can also check that if there is an unexpected mixed using of both apple sandbox and production push on a same environment(or database). This may cause unexpected deletion of deviceToken.
@wicked-wei the sandbox was used by 20 beta-testers only.
When we set PARSE_SERVER_CLEANUP_INVALID_INSTALLATIONS flag, nothing bad happened at first, but then in 3 days we started getting complaints from both sandbox users and production users. Why were the production users affected by this flag?
@halvini because sandbox and production use different deviceToken. If any chance you send a production deviceToken to a sandbox apns server, it will report that token is BadToken. Reverse is the same.
@wicked-wei ok, so why did production users lose their deviceToken data, if we send push notifications from cloud code only? The parse-server config has both certificates installed:
"PARSE_SERVER_PUSH": {
"android": {
"senderId": "*****",
"apiKey": "*****"
},
"ios": [
{
"pfx": "*****/developmentPush.p12",
"topic": "*****",
"production": false
},
{
"pfx": "*****/productionPush.p12",
"topic": "****",
"production": true
}
]
},
@halvini the config looks ok, but I am not sure if parse server can tell a installation deviceToken is production or sandbox. For the js documents does not mention that, maybe it will send a token to both production or sandbox? I am not sure because I never do that. Oh, I forgot that. The installation has 'appIdentifier' field to tell deviceToken belongs app. So If you config two pfx with different topic, that will be Ok.
@wicked-wei , this is all quite informative, but it doesn't resolve the issue of undefined deviceTokens for valid ios installations.
Your idea is to change the development certificate to a new bundle id, am I right? How can I be sure that that's the reason? I can't risk my production environment again. I've lost too much data when I set the PARSE_SERVER_CLEANUP_INVALID_INSTALLATIONS flag. It worked for a few days only but resulted in a huge mess.
Did anyone find a solution to this issue?
I'd like to set the PARSE_SERVER_CLEANUP_INVALID_INSTALLATIONS to 1 without losing valid iOS installations.
Any update here? is PARSE_SERVER_CLEANUP_INVALID_INSTALLATIONS safe to use? Are there docs on it?
im interested in this as well. just for the sake of keeping logs clean
@alexblack @jeffreyjackson the only way to know if it's safe to use is for you guys to use it and report your findings.
Well, there are some findings above, sounds risky, we'll find another way.
we'll find another way.
That's not really helpful as the gate behind the feature flag is for the community to experiment. I'd rather revert the PR / feature if no one is willing to experiment with us.
Fair point. I should share my other feedback - also not too excited about the feature in general, if device tokens are erased then it seems to make it harder to distinguish installations with no device token vs ones that were erased.
This combined with the lack of real errors/transparency from parse push means we'll eventually just integrate with apple and google, then we'll have real errors back, and we can just mark installations as unreachable when we learn that from the source.
Also as we've reported parse-dashboard doesn't display past pushes for us. So we're not really having a great experience here.
also not too excited about the feature in general, if device tokens are erased then it seems to make it harder to distinguish installations with no device token vs ones that were erased.
This is what you were expecting originally, that this feature is working correctly, not sure where you're coming from with that.
This combined with the lack of real errors/transparency from parse push means we'll eventually just integrate with apple and google, then we'll have real errors back, and we can just mark installations as unreachable when we learn that from the source.
I'm open for improving the project / provide a better feature but without community feedback this is unfortunately impossible.
Opensource doesn't mean we the maintainers have to take all the risks and responsibility.
The community pressed to have a cleanup invalid token implemented, IIRC you were part of it, I spent a shit load of hours on it, a tentative implementation has been available for a while and now you're pressing again today to have something else implemented. Do you understand how unfair, unethical and unwelcome those commentaries are?
I don't remember pressing to have device tokens erased, but, if I did, and now I realized that having them not erased would be better, I apologize for my lack of foresight.
Any update here? is PARSE_SERVER_CLEANUP_INVALID_INSTALLATIONS safe to use? Are there docs on it?
@alexblack that's not what I call sharing feedback, but waiting-for-someone-else-to-do-some-work-for-me.
Sharing feedback would have been to open issues, discuss potential improvements and most importantly, identify if there's any issue with the approach. What would be the best solution for you?
Now, we gather all error reports from the adapter, and list the installations that fail. Removing their token is what's expected from GCM or APNs. What's missing?