135 deviceType must be specified in this operation

[alexblack]

A lot of my users encounter this error, I can't repro it, not sure what is going on. I'm using SDK 1.10.3. I first opened this issue on June 4th:

https://developers.facebook.com/bugs/903903186334036/

http://crashes.to/s/8a6fe6eb94f

"Failed to save parse installation: 135"

java.lang.Exception: com.parse.ph: deviceType must be specified in this operation
       at com.aadhk.woinvoice.util.ParseInit$2.then(ProGuard:163)
       at com.aadhk.woinvoice.util.ParseInit$2.then(ProGuard:156)
       at bolts.Task$15.run(ProGuard:825)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeAfterTask(ProGuard:816)
       at bolts.Task.access$200(ProGuard:32)
       at bolts.Task$11.then(ProGuard:621)
       at bolts.Task$11.then(ProGuard:618)
       at bolts.Task.runContinuations(ProGuard:861)
       at bolts.Task.access$600(ProGuard:32)
       at bolts.Task$TaskCompletionSource.trySetError(ProGuard:932)
       at bolts.Task$TaskCompletionSource.setError(ProGuard:959)
       at bolts.Task$15$1.then(ProGuard:840)
       at bolts.Task$15$1.then(ProGuard:829)
       at bolts.Task$14.run(ProGuard:784)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeImmediately(ProGuard:775)
       at bolts.Task.access$100(ProGuard:32)
       at bolts.Task$10.then(ProGuard:567)
       at bolts.Task$10.then(ProGuard:564)
       at bolts.Task.runContinuations(ProGuard:861)
       at bolts.Task.access$600(ProGuard:32)
       at bolts.Task$TaskCompletionSource.trySetError(ProGuard:932)
       at bolts.Task$TaskCompletionSource.setError(ProGuard:959)
       at bolts.Task$15$1.then(ProGuard:840)
       at bolts.Task$15$1.then(ProGuard:829)
       at bolts.Task$14.run(ProGuard:784)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeImmediately(ProGuard:775)
       at bolts.Task.access$100(ProGuard:32)
       at bolts.Task$10.then(ProGuard:567)
       at bolts.Task$10.then(ProGuard:564)
       at bolts.Task.runContinuations(ProGuard:861)
       at bolts.Task.access$600(ProGuard:32)
       at bolts.Task$TaskCompletionSource.trySetError(ProGuard:932)
       at bolts.Task$TaskCompletionSource.setError(ProGuard:959)
       at bolts.Task$15$1.then(ProGuard:840)
       at bolts.Task$15$1.then(ProGuard:829)
       at bolts.Task$14.run(ProGuard:784)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeImmediately(ProGuard:775)
       at bolts.Task.continueWith(ProGuard:574)
       at bolts.Task.continueWith(ProGuard:585)
       at bolts.Task$15.run(ProGuard:829)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeAfterTask(ProGuard:816)
       at bolts.Task.access$200(ProGuard:32)
       at bolts.Task$11.then(ProGuard:621)
       at bolts.Task$11.then(ProGuard:618)
       at bolts.Task.runContinuations(ProGuard:861)
       at bolts.Task.access$600(ProGuard:32)
       at bolts.Task$TaskCompletionSource.trySetError(ProGuard:932)
       at bolts.Task$TaskCompletionSource.setError(ProGuard:959)
       at bolts.Task$15$1.then(ProGuard:840)
       at bolts.Task$15$1.then(ProGuard:829)
       at bolts.Task$14.run(ProGuard:784)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeImmediately(ProGuard:775)
       at bolts.Task.access$100(ProGuard:32)
       at bolts.Task$10.then(ProGuard:567)
       at bolts.Task$10.then(ProGuard:564)
       at bolts.Task.runContinuations(ProGuard:861)
       at bolts.Task.access$600(ProGuard:32)
       at bolts.Task$TaskCompletionSource.trySetError(ProGuard:932)
       at bolts.Task$TaskCompletionSource.setError(ProGuard:959)
       at bolts.Task$15$1.then(ProGuard:840)
       at bolts.Task$15$1.then(ProGuard:829)
       at bolts.Task$14.run(ProGuard:784)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeImmediately(ProGuard:775)
       at bolts.Task.access$100(ProGuard:32)
       at bolts.Task$10.then(ProGuard:567)
       at bolts.Task$10.then(ProGuard:564)
       at bolts.Task.runContinuations(ProGuard:861)
       at bolts.Task.access$600(ProGuard:32)
       at bolts.Task$TaskCompletionSource.trySetError(ProGuard:932)
       at bolts.Task$TaskCompletionSource.setError(ProGuard:959)
       at bolts.Task$15$1.then(ProGuard:840)
       at bolts.Task$15$1.then(ProGuard:829)
       at bolts.Task$14.run(ProGuard:784)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeImmediately(ProGuard:775)
       at bolts.Task.continueWith(ProGuard:574)
       at bolts.Task.continueWith(ProGuard:585)
       at bolts.Task$15.run(ProGuard:829)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeAfterTask(ProGuard:816)
       at bolts.Task.access$200(ProGuard:32)
       at bolts.Task$11.then(ProGuard:621)
       at bolts.Task$11.then(ProGuard:618)
       at bolts.Task.runContinuations(ProGuard:861)
       at bolts.Task.access$600(ProGuard:32)
       at bolts.Task$TaskCompletionSource.trySetError(ProGuard:932)
       at bolts.Task$TaskCompletionSource.setError(ProGuard:959)
       at bolts.Task$15$1.then(ProGuard:840)
       at bolts.Task$15$1.then(ProGuard:829)
       at bolts.Task$14.run(ProGuard:784)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeImmediately(ProGuard:775)
       at bolts.Task.continueWith(ProGuard:574)
       at bolts.Task.continueWith(ProGuard:585)
       at bolts.Task$15.run(ProGuard:829)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeAfterTask(ProGuard:816)
       at bolts.Task.access$200(ProGuard:32)
       at bolts.Task$11.then(ProGuard:621)
       at bolts.Task$11.then(ProGuard:618)
       at bolts.Task.runContinuations(ProGuard:861)
       at bolts.Task.access$600(ProGuard:32)
       at bolts.Task$TaskCompletionSource.trySetError(ProGuard:932)
       at bolts.Task$TaskCompletionSource.setError(ProGuard:959)
       at bolts.Task$15$1.then(ProGuard:840)
       at bolts.Task$15$1.then(ProGuard:829)
       at bolts.Task$14.run(ProGuard:784)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeImmediately(ProGuard:775)
       at bolts.Task.continueWith(ProGuard:574)
       at bolts.Task.continueWith(ProGuard:585)
       at bolts.Task$15.run(ProGuard:829)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
       at java.lang.Thread.run(Thread.java:818)
Caused by: com.parse.ph: deviceType must be specified in this operation
       at com.parse.ParseRequest.onResponseAsync(ProGuard:301)
       at com.parse.ParseRESTCommand.onResponseAsync(ProGuard:288)
       at com.parse.ParseRequest$3.then(ProGuard:151)
       at com.parse.ParseRequest$3.then(ProGuard:147)
       at bolts.Task$15.run(ProGuard:825)
       at bolts.BoltsExecutors$ImmediateExecutor.execute(ProGuard:105)
       at bolts.Task.completeAfterTask(ProGuard:816)
       at bolts.Task.continueWithTask(ProGuard:628)
       at bolts.Task.continueWithTask(ProGuard:639)
       at bolts.Task$13.then(ProGuard:731)
       at bolts.Task$13.then(ProGuard:719)
       at bolts.Task$15.run(ProGuard:825)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
       at java.lang.Thread.run(Thread.java:818)

Here is a snippet of my code in this stack trace:

public Task<ParseInstallation> initParseInstallation() {
    final TimingLogger timings = new TimingLogger(TAG, "initParseInstallation");
    Log.d(TAG, "initParseInstallation");
    try {
      final ParseInstallation installation = ParseInstallation.getCurrentInstallation();
      installation.put("flavor", BuildConfig.FLAVOR);
      installation.put("accountId", accountId);
      installation.put("user", ParseUser.getCurrentUser());
      try {
        installation.put("androidId", Settings.Secure.getString(ctx.getContentResolver(), Settings.Secure.ANDROID_ID));
        installation.put("android", String.format("%s (%s %s)", Build.VERSION.RELEASE, Build.VERSION.CODENAME, Build.VERSION.INCREMENTAL));
        installation.put("device", String.format("%s (%s)", DeviceUtils.getDeviceName(), Build.HARDWARE));
        installation.put("abi", Build.CPU_ABI);
        installation.put("syncEnabled", Syncer.syncEnabled(ctx));
        installation.increment("appStart");
      } catch (Exception e) {
        App.err(ctx, "Failed to set properties on installation", e);
      }

      if (installation.containsKey("GCMSenderId"))
        installation.remove("GCMSenderId");

      timings.addSplit("setInstall");

      return installation.saveInBackground().continueWithTask(new Continuation<Void, Task<ParseInstallation>>() {
        @Override
        public Task<ParseInstallation> then(Task<Void> task) throws Exception {
          timings.addSplit("onInstall");
          if (task.isFaulted()) {
            if (task.getError() instanceof ParseException) {
              ParseException e = (ParseException) task.getError();
              App.err(ctx, "Failed to save parse installation: " + e.getCode(), new Exception(e));
            } else {
              App.err(ctx, "Failed to save parse installation", new Exception(task.getError()));
            }
            return Task.forError(task.getError());
          } else {
            Log.d(TAG, "Successfully initialized parseInstallation: " + installation.getObjectId());
            return Task.forResult(installation);
          }
        }
      });
    } catch (Exception e) {
      App.err(ctx, "Failed to setup parse installation", e);
      return Task.forError(e);
    }
  }

[grantland]

This looks to be a valid bug!

The only the situation where deviceType wouldn't be set would be if the SDK doesn't think the current ParseInstallation is current here. It also looks like there could be a race condition where two ParseInstallations could be created and returned from ParseInstallation.getCurrentInstallation() here.

We won't be able to fully guarantee it'll resolve your issue since there isn't a stable repro for your situation, but it'll be better than nothing.

[alexblack]

Great - does that mean you (or someone) will attempt a fix?

Is there anything I can do in the meantime to work around this? If the parseInstallation doesn't get saved then I can't send push notifications.

[grantland]

Sorry, ran off to a meeting before assigning myself.

TL;DR: There's no workaround, but the problem isn't as bad as you think.

If the above is correct, there are two different "current" ParseInstallations in the process on first app launch since no "current" ParseInstallation exists on disk. One is in your code's context where you're adding custom information and the other is in the SDK's context where it's registering GCM. Only one can be "current" and both have equal probability of being "current".

Right now we only have reports of failures from your code's context and it's plausible that the on in the SDK fails as well, but only one or the other and not both. Therefore failure cases will result in either the GCM registration information will be persisted or your custom information will be persisted, but a ParseInstallation will always get persisted on disk. This ParseInstallation on disk will then be read on next app launch and any missing data will be persisted to Parse since the on disk ParseInstallation will definitely have deviceToken, as long as your custom code allows this.

In the end, the probability of a device not having a GCM registration information after the first launch is very low and nonexistent upon relaunch.

[alexblack]

That sounds promising. But a lot of my users won't have a relaunch, eg
they are just kicking the tires, they might stick around if they like the
app and it works well
On Oct 20, 2015 5:34 PM, "Grantland Chew" notifications@github.com wrote:

Sorry, ran off to a meeting before assigning myself.

TL;DR: There's no workaround, but the problem isn't as bad as you think.

If the above is correct, there are two different "current"
ParseInstallations in the process on first app launch since no "current"
ParseInstallation exists on disk. One is in your code's context where
you're adding custom information and the other is in the SDK's context
where it's registering GCM. Only one can be "current" and both have equal
probability of being "current".

Right now we only have reports of failures from your code's context and
it's plausible that the on in the SDK fails as well, but only one or the
other and not both. Therefore failure cases will result in either the GCM
registration information will be persisted or your custom information will
be persisted, but a ParseInstallation will always get persisted on disk.
This ParseInstallation on disk will then be read on next app launch and
any missing data will be persisted to Parse since the on disk
ParseInstallation will definitely have deviceToken, as long as your
custom code allows this.

In the end, the probability of a device not having a GCM registration
information after the first launch is very low and nonexistent upon
relaunch.

—
Reply to this email directly or view it on GitHub
#203 (comment)
.

[grantland]

If that's the case, a possible workaround is to add your own retry logic from fetching the "current" ParseInstallation pointer, adding all your properties, and saving if the error code is 135.

[alexblack]

Cool, I'll try that. Just checking I understand - do I just need to retry the same logic I already have? or does the 2nd attempt need to do something different?

[grantland]

Same thing, I just wanted to reiterate that you need to make sure you operate on a fresh value returned from ParseInstallation.getCurrentInstallation()

[alexblack]

Gotcha, thanks!

[alexblack]

Do you know when the next SDK release might be so I can try this out? Or, do you ever publish interim binaries I could try?

[alexblack]

Hmm, I'm not convinced this is the issue. I have one user who has had this error 298 times, ParseInstallation KSuNvq8VWj. He first saw the issue July 11th when he installed

msg Failed to save parse installation: 135 
ex  at least one ID field (installationId,deviceToken) must be specified in this operation 
stacktrace  com.parse.nc: at least one ID field (installationId,deviceToken) must be specified in this operation at com.parse.mp.a(ProGuard:391) at com.parse.me.a(ProGuard:197) at com.parse.ms.b(ProGuard:258) at com.parse.ms.a(ProGuard:254) at a.q.run(ProGuard:796) at a.g.execute(ProGuard:105) at a.k.d(ProGuard:787) at a.k.b(ProGuard:599) at a.k.b(ProGuard:610) at a.o.b(ProGuard:702) at a.o.a(ProGuard:690) at a.q.run(ProGuard:796) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587) at java.lang.Thread.run(Thread.java:818)  
errid   c5e38848-cc5a-43ec-a6f2-7fef6a28e643 
name    error 

He gets the error when trying to save objects that reference his installation too (this error here happened today using the latest version of my app which uses the latest parse sdk)

msg Failed to saved parseMsg for msgRemoteId 9093de37-3392-4f19-a85b-6fc9a4047c45 
ex  com.parse.ph: deviceType must be specified in this operation 
stacktrace  java.lang.Exception: com.parse.ph: deviceType must be specified in this operation at com.aadhk.woinvoice.util.ap.b(ProGuard:472) at com.aadhk.woinvoice.util.ap.a(ProGuard:466) at a.u.run(ProGuard:825) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587) at java.lang.Thread.run(Thread.java:818) Caused by: com.parse.ph: deviceType must be specified in this operation at com.parse.oz.a(ProGuard:301) at com.parse.ol.a(ProGuard:288) at com.parse.pc.b(ProGuard:151) at com.parse.pc.a(ProGuard:147) at a.u.run(ProGuard:825) at a.h.execute(ProGuard:105) at a.n.d(ProGuard:816) at a.n.b(ProGuard:628) at a.n.b(ProGuard:639) at a.s.b(ProGuard:731) at a.s.a(ProGuard:719) ... 4 more  
errid   40f12282-a344-4dc0-98f7-593f5ecc6920 
name    error 
appversion  0.1.171 

This doesn't seem to line up with your description of a race condition that goes away on 2nd app launch.