Skip to content

error:135 deviceType must be specified in this operation Parse v 1.14.1 #627

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

Closed
ClarkXP opened this issue Apr 5, 2017 · 6 comments
Closed

Comments

@ClarkXP
Copy link

ClarkXP commented Apr 5, 2017

Hi, I had the error in my app, exists any workaround for this error.
The field 'deviceType' is read only in ParseInstallation, so I don't know how to fix it.
The unique solution was delete all application data and relogin, but I can't do it with my users.

@natario1
Copy link
Contributor

natario1 commented Apr 6, 2017

Your users are experiencing this or just you in your test device?

ParseInstallation is often messed up when switching between debug / release APKs, different build variants, ... Ideally you would want debug APKs to connect to a different app with different app id.

@hermanliang
Copy link
Contributor

It seems to be related to the #611, #607, and #579.
Have you done any similar operations?
As @natario1 said, if you switch different parse server (database) with the same applicationId, it may cause problems by mixing the cached data.

@ClarkXP
Copy link
Author

ClarkXP commented Apr 6, 2017

Yes, I can confirm that the issue started when I switched the build variant from debug to release. So the session was revoked and started the issue.

@hermanliang
Copy link
Contributor

We may add this logic to the installation re-save process.
@rogerhu What do you think?

@ClarkXP during the meantime, you may trigger the re-save process yourself when you get code 135.

if (e.getCode() == 135 && installation.getObjectId() == null) {
  installation.setObjectId("objectId"); // set a fake objectId
  installation.saveInBackground(); // it will trigger resave process due to object not found in the server
}

Note: setObjectId will not be available after #611 is merged.

@rogerhu
Copy link
Contributor

rogerhu commented Apr 30, 2017

Should be fixed now right?

@hermanliang
Copy link
Contributor

@ClarkXP This issue should be resolved since v.1.15.2. If you still encounter the same issue, you can provide additional information to reopen it.

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

No branches or pull requests

4 participants