Skip to content
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

BadDeviceToken - Test and production environments #483

Closed
rwillett opened this issue Feb 11, 2019 · 5 comments
Closed

BadDeviceToken - Test and production environments #483

rwillett opened this issue Feb 11, 2019 · 5 comments

Comments

@rwillett
Copy link

Hi,

We are trying to work out what is best practise for testing and production use of OneSignal. We are getting the following error message from OneSignal when we check the Sandbox environment for our app.

Mismatched User Environment (Sandbox)
Apple returned a BadDeviceToken error. Some users are tied to a different environment from your sending environment.

This warning occurred 678 times, last occurring about 22 hours ago.

Affected users: <<REDACTED>> and <<REDACTED>

Help me fix this

We think this is due to our use of the same iPhone for both production use and test use. We will install our app for production use and then reinstall our app for test use.

We have two environments with OneSignal, each with different keys, one production and one sandbox. If we are using a non production build, we point our app at the OneSignal sandbox and if we are going production we register with the production OneSignal environment.

We aren't clear what best practise is for using the same phone for testing in a demo environment and testing in production. We thought having two environments would be the right thing to do, but it appears that we've got this wrong.

We do not believe the issue is related to #428 as we have updated our command line tools months ago when we went to Xcode 10. As per normal Apple documentation is of zero help.

We think we need to ensure that any phone that moves between the Sandbox and the Production environments needs to de-register in the other environment. If this is the case, the only thing we can see is SetSubscription (https://documentation.onesignal.com/docs/cordova-sdk#section--setsubscription-).

The logic of SetSubscription appears to mean that we would have to register with one environment (e.g. production) to then SetSubscription(false), then register with the demo environment to SetSubscription(true) or vice versa. The Server Rest API doesn't appear to give me the option to remove a device BUT the Add Device with Test_Type = 1, seems to give a hint this might work.

Any help or suggestions as to the way forward appreciated.

Thanks

Rob

@logusgraphics
Copy link

Same issue

@ghost
Copy link

ghost commented Mar 26, 2019

Same issue as well!

@jkasten2
Copy link
Member

@rwillett Sorry for the delay, thanks for providing all this detail. #428 caused the opposite effect of what you are seeing, development devices being counted as production so you are correct in this wouldn't be the cause of this issue.

If you use the same bundle id for development builds and production builds using the same OneSignal app should be fine. I would recommend uninstalling the app, instead of installing over the app. Our SDK should still update the device event if you don't uninstall however we don't regularly test this scenario so there is a possibly this is the issue.

@rgomezp
Copy link
Contributor

rgomezp commented Apr 29, 2019

@rwillett ,
Was wondering if you saw jkasten2's response.

Thanks

@rgomezp rgomezp closed this as completed May 6, 2019
@rwillett
Copy link
Author

@rgomezp
Apologies, only just realised I never responded to @jkasten2 comment.

We've got the same problem again and we think it's caused by having a device working on the sandbox and then moving it to production.

I'll raise a separate issue for it and reference this one.

Thanks and apologies appropriately.

Thanks

Rob

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants