Make loading of PFInstallation.currentInstallation() fully async.

[fluidsonic]

A crash was reported which was caused by an exception thrown by Parse SDK 1.12.0.
It originates from a simple call to PFInstallation.currentInstallation().

Here's the relevant stack trace from the crash log:

+[NSException raise:format:] (NSException.m:140)
-[PFObject(Private) _setObject:forKey:onlyIfDifferent:] (PFObject.m:1485)
__56-[PFCurrentInstallationController getCurrentObjectAsync]_block_invoke35 (PFCurrentInstallationController.m:127)

(different thread)

-[BFTask(Private) waitForResult:withMainThreadWarning:] (BFTask+Private.m:125)
+[PFInstallation currentInstallation] (PFInstallation.m:136)

The offending line PFCurrentInstallationController.m:127 is

installation.installationId = installationId;

So installationId is likely nil for some reason.

[nlutsenko]

InstallationId is guaranteed to be non-nil at all times, so this should never happen.
You run into some really weird inconsistency in this case.

Any chance you can trace PFInstallationIdentifierStore and look at why the installationId inside of it becomes nil?

[fluidsonic]

Unfortunately we cannot reproduce the bug. It was one lone user out there in the wild who caused and reported that crash.

I'm digging through the sources but the installation ID retrieval looks quite complex :/

• What happens if the installationId file is inaccessible (probably locked)? Can that happen?
• Can anything suddenly become nil? The strongified selfs maybe?
  Since this is Objective-C code it's not necessarily the installationId being nil but any variable used during the process of retrieving it. Difficult to tell.
• Sneaky race condition maybe?

Here's more of the stack trace - all from Bolts. It indicates that there were errors earlier in the task chain. I have no idea though how to read this trace.

+[NSException raise:format:] (NSException.m:140)
-[PFObject(Private) _setObject:forKey:onlyIfDifferent:] (PFObject.m:1485)
__56-[PFCurrentInstallationController getCurrentObjectAsync]_block_invoke35 (PFCurrentInstallationController.m:127)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:336)
__29+[BFExecutor defaultExecutor]_block_invoke_2 (BFExecutor.m:63)
-[BFExecutor execute:] (BFExecutor.m:129)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke (BFTask.m:328)
-[BFTask runContinuations] (BFTask.m:308)
-[BFTask trySetResult:] (BFTask.m:223)
-[BFTaskCompletionSource setResult:] (BFTaskCompletionSource.m:50)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_3 (BFTask.m:352)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:336)
__29+[BFExecutor defaultExecutor]_block_invoke_2 (BFExecutor.m:63)
-[BFExecutor execute:] (BFExecutor.m:129)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke (BFTask.m:328)
-[BFTask runContinuations] (BFTask.m:308)
-[BFTask trySetResult:] (BFTask.m:223)
-[BFTaskCompletionSource setResult:] (BFTaskCompletionSource.m:50)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_3 (BFTask.m:352)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:360)
__29+[BFExecutor defaultExecutor]_block_invoke_2 (BFExecutor.m:63)
-[BFExecutor execute:] (BFExecutor.m:129)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke (BFTask.m:328)
-[BFTask runContinuations] (BFTask.m:308)
-[BFTask trySetResult:] (BFTask.m:223)
-[BFTaskCompletionSource setResult:] (BFTaskCompletionSource.m:50)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_3 (BFTask.m:352)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:336)
__29+[BFExecutor defaultExecutor]_block_invoke_2 (BFExecutor.m:63)
-[BFExecutor execute:] (BFExecutor.m:129)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke (BFTask.m:328)
-[BFTask runContinuations] (BFTask.m:308)
-[BFTask trySetResult:] (BFTask.m:223)
-[BFTaskCompletionSource setResult:] (BFTaskCompletionSource.m:50)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:366)
__29+[BFExecutor defaultExecutor]_block_invoke_2 (BFExecutor.m:63)
-[BFExecutor execute:] (BFExecutor.m:129)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke (BFTask.m:328)
-[BFTask runContinuations] (BFTask.m:308)
-[BFTask trySetResult:] (BFTask.m:223)
-[BFTaskCompletionSource setResult:] (BFTaskCompletionSource.m:50)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_3 (BFTask.m:352)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:360)
__29+[BFExecutor defaultExecutor]_block_invoke_2 (BFExecutor.m:63)
-[BFExecutor execute:] (BFExecutor.m:129)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke (BFTask.m:328)
-[BFTask runContinuations] (BFTask.m:308)
-[BFTask trySetError:] (BFTask.m:242)
-[BFTaskCompletionSource setError:] (BFTaskCompletionSource.m:57)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_3 (BFTask.m:352)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:360)
__29+[BFExecutor defaultExecutor]_block_invoke_2 (BFExecutor.m:63)
-[BFExecutor execute:] (BFExecutor.m:129)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke (BFTask.m:328)
-[BFTask runContinuations] (BFTask.m:308)
-[BFTask trySetError:] (BFTask.m:242)
-[BFTaskCompletionSource setError:] (BFTaskCompletionSource.m:57)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_3 (BFTask.m:352)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:336)
__29+[BFExecutor defaultExecutor]_block_invoke_2 (BFExecutor.m:63)
-[BFExecutor execute:] (BFExecutor.m:129)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke (BFTask.m:328)
-[BFTask runContinuations] (BFTask.m:308)
-[BFTask trySetError:] (BFTask.m:242)
-[BFTaskCompletionSource setError:] (BFTaskCompletionSource.m:57)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_3 (BFTask.m:352)
__55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 (BFTask.m:360)

[nlutsenko]

Yeah, unfortunately the stack traces from Bolts don't quite help :(
Let me try my best to answer the questions above, first:

What happens if the installationId file is inaccessible (probably locked)? Can that happen?

Since we have a single entry point for that file and it's consistency is managed runtime by a single dispatch queue - not sure it's a consistency problem here. What might be happening is it's failing on writing/reading data from disc, which might lead to this. I'll think about how we can guarantee more safety here.

Can anything suddenly become nil? The strongified selfs maybe?

Things can become nil, for sure, but we have an explicit guarantee on a single PFInstallationIdentifierStore and single PFCurrentInstallationController per entire runtime of the application, so unless you are changing applicationId inflight (which has undefined behavior), this shouldn't affect it.

Since this is Objective-C code it's not necessarily the installationId being nil but any variable used during the process of retrieving it. Difficult to tell.

Same, the entire pipeline is guaranteed to be non-nil, or we have bigger problems than installationId.

Sneaky race condition maybe?

Quite possibly, also things like moon-phase actually affect software. 😛

Overall, I think we can make the entire pipeline safer, by avoiding usage of synchronous blocking wait there and chaining the entire promise chain on another async task, which will guarantee graceful error handling in a scenario when disk i/o or anything like this fails. Turns out there is also a todo to make it not terrible, so this is pending anyhow. Marking this issue as enhancement.

Little more details on pending work:
We have a waitForResult() when requesting installationIdentifier, which already yields a task here. The work would require removal of waitForResult() and chaining the entire promise chain on loading the installation identifier, so in a case of nil installationId we don't crash the entire runtime.

[fluidsonic]

Hey. Is there any news regarding this issue?
We got feedback from multiple users now that our app crashes on startup and we got several new crash reports related to PFInstallation.currentInstallation().

Any recommendation to work around this issue?

[fluidsonic]

Hey @nlutsenko,

we released a new app version using Parse 1.13.0 where this issue was supposed to be resolved.
Unfortunately it isn't fixed and first day after launch we got another crash report:
https://gist.github.com/fluidsonic/723761772ef388c5b07f4dab5c951370

[nlutsenko]

@fluidsonic Super sad to hear that. 1.14.0 is going to have the new API for getting the installation - getInstallationInBackground that gives you an option to handle the error.

[nlutsenko]

Let me reopen this issue and verify that we have all the possible error handling there as well as we never get nil installationId.

[nlutsenko]

Found another possible improvement - attached #901.
Will be released as part of 1.14.0