objectId should be non nil

[carbonimax]

Hi,

Since a few weeks, at app launch, for some users (±0.1%), the app crashes on PFRESTObjectCommand.m line 21 with this error:

Fatal Exception: NSInvalidArgumentException
objectId should be non nil

At launch, we sync the current PFUser and we call PFUser.enableAutomaticUser().
I don't know which object could have a nil objectId.
If I add some debug, currentUser.objectId and currentUser.session are OK.

PFObject._validateFetchAsync is called just before Just before PFRestObjectCommand.fetchObjectCommandForObjectState:withSessionToken and it doesn't catch some invalid objectId.

A re-installation of the app correct the problem.

Do you have any idea where this might be coming from?

[carbonimax]

trace

objectId should be non nil
Fatal Exception: NSInvalidArgumentException
0  CoreFoundation                 0x1a3488300 __exceptionPreprocess
1  libobjc.A.dylib                0x1a319cc1c objc_exception_throw
2  CoreFoundation                 0x1a3377e68 -[NSCache init]
3  Parse                          0x101423cc8 +[PFRESTObjectCommand fetchObjectCommandForObjectState:withSessionToken:] + 21 (PFRESTObjectCommand.m:21)
4  Parse                          0x1013eff8c __56-[PFObjectController fetchObjectAsync:withSessionToken:]_block_invoke.10 + 55 (PFObjectController.m:55)
5  Bolts                          0x100ea1f94 __62-[BFTask continueWithExecutor:successBlock:cancellationToken:]_block_invoke + 398 (BFTask.m:398)
6  Bolts                          0x100ea198c __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke + 331 (BFTask.m:331)
7  Bolts                          0x100e9f5ac __29+[BFExecutor defaultExecutor]_block_invoke_2 + 66 (BFExecutor.m:66)
8  Bolts                          0x100e9fad8 -[BFExecutor execute:] + 131 (BFExecutor.m:131)
9  Bolts                          0x100ea158c -[BFTask runContinuations] + 308 (BFTask.m:308)
10 Bolts                          0x100ea10f4 -[BFTask trySetResult:] + 247 (BFTask.m:247)
11 Bolts                          0x100ea25bc -[BFTaskCompletionSource setResult:] + 45 (BFTaskCompletionSource.m:45)
12 Bolts                          0x100ea1b90 __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke_2 + 340 (BFTask.m:340)
13 Bolts                          0x100ea1a40 __55-[BFTask continueWithExecutor:block:cancellationToken:]_block_invoke + 348 (BFTask.m:348)
14 libdispatch.dylib              0x1a3126ec4 _dispatch_call_block_and_release
15 libdispatch.dylib              0x1a312833c _dispatch_client_callout
16 libdispatch.dylib              0x1a312a7b4 _dispatch_queue_override_invoke
17 libdispatch.dylib              0x1a31375c0 _dispatch_root_queue_drain
18 libdispatch.dylib              0x1a3137d9c _dispatch_worker_thread2
19 libsystem_pthread.dylib        0x1a318f6d8 _pthread_wqthread
20 libsystem_pthread.dylib        0x1a31959c8 start_wqthread

[SebC99]

@TomWFox @mtrezza have you already seen something like this?
Why is there even a [BFTask continueWithExecutor before the _validateFetchAsync test whereas it's a sync test (just a if)? Can't we removed that to avoid any potential race condition issue?
BTW, the validation test the existence of the objectId whereas the assert test the length of that objectId, so that a weird "" objectId could pass the first test, but fail on the assert (I don't know how we could have a "" objectId of course)

[drdaz]

If I add some debug, currentUser.objectId and currentUser.session are OK.

Where are they 'okay'? Are they are non-nil when the check claims they're nil?

[carbonimax]

In application:didFinishLaunchingWithOptions, after Parse init, objectIds are never nil and sessions are valid (except for new users but it is normal and it doesn't crash).
In all debug prints in app, they are never nil and always valid before the crash, from what I can see.

[drdaz]

@carbonimax That sounds pretty strange. The only times I recall seeing similar behaviour (and not in Parse) involved threading issues. Where values were being set on one thread and tested in another.

I'm not sure that's what you're seeing here (I recall PFObjects being thread-safe in fact), but it's the first thing that jumps to mind.

[mtrezza]

Since a few weeks, at app launch, for some users (±0.1%), the app crashes on PFRESTObjectCommand.m line 21

Does the date coincide with an app update / release date (mind the rollout duration)? Then again, "some users (±0.1%)" doesn't sound like a significant volume :)

have you already seen something like this?

I have seen a similar issue regarding PFUser.currentUser() on iOS, I assumed a threading issue. That is what I would be looking at here at first. For example when the current user is logged in or out, while there are requests being made on different threads.

[SebC99]

Does someone have any idea of the purpose of the first BFTask in:

- (BFTask *)fetchObjectAsync:(PFObject *)object withSessionToken:(NSString *)sessionToken {
    @weakify(self);
    return [[[[BFTask taskFromExecutor:[BFExecutor defaultPriorityBackgroundExecutor] withBlock:^id{
        return [object _validateFetchAsync];
    }] continueWithSuccessBlock:^id(BFTask *task) {
        @strongify(self);
        PFRESTCommand *command = [PFRESTObjectCommand fetchObjectCommandForObjectState:[object._state copy]
                                                                      withSessionToken:sessionToken];
        return [self _runFetchCommand:command forObject:object];
    }] continueWithSuccessBlock:^id(BFTask *task) {
        @strongify(self);
        PFCommandResult *result = task.result;
        return [self processFetchResultAsync:result.result forObject:object];
    }] continueWithSuccessResult:object];
}

The call to [object _validateFetchAsync] is a simple (sync) test on !self._state.objectId so I don't see why there's a BFTask involved.
Even the change of queue is unnecessary as it will be done in the [self _runFetchCommand:command forObject:object]; call.

[drdaz]

Does someone have any idea of the purpose of the first BFTask in:

- (BFTask *)fetchObjectAsync:(PFObject *)object withSessionToken:(NSString *)sessionToken {
    @weakify(self);
    return [[[[BFTask taskFromExecutor:[BFExecutor defaultPriorityBackgroundExecutor] withBlock:^id{
        return [object _validateFetchAsync];
    }] continueWithSuccessBlock:^id(BFTask *task) {
        @strongify(self);
        PFRESTCommand *command = [PFRESTObjectCommand fetchObjectCommandForObjectState:[object._state copy]
                                                                      withSessionToken:sessionToken];
        return [self _runFetchCommand:command forObject:object];
    }] continueWithSuccessBlock:^id(BFTask *task) {
        @strongify(self);
        PFCommandResult *result = task.result;
        return [self processFetchResultAsync:result.result forObject:object];
    }] continueWithSuccessResult:object];
}

The call to [object _validateFetchAsync] is a simple (sync) test on !self._state.objectId so I don't see why there's a BFTask involved.
Even the change of queue is unnecessary as it will be done in the [self _runFetchCommand:command forObject:object]; call.

Maybe consistency? The SDK is big on BFTask. Or maybe there are historical reasons it's like that?

But I agree it seems like less fancy could do the same job.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If you believe it should stay open, please let us know! As always, we encourage contributions, check out the Contributing Guide