Firestore blows up on GET {source: "cache"} if document exists in cache

[scottmas]

Issue

When I request a document with {source: 'cache'} that already exists, the library blows up with a native error (not a nice wrapped one):

'NSInvalidArgumentException', reason: '-[FSTDeletedDocument data]: unrecognized selector sent to instance 0x600000244230'
*** First throw call stack:
(
	0   CoreFoundation                      0x0000000110da91e6 __exceptionPreprocess + 294
	1   libobjc.A.dylib                     0x000000010f695031 objc_exception_throw + 48
	2   CoreFoundation                      0x0000000110e2a784 -[NSObject(NSObject) doesNotRecognizeSelector:] + 132
	3   CoreFoundation                      0x0000000110d2b898 ___forwarding___ + 1432
	4   CoreFoundation                      0x0000000110d2b278 _CF_forwarding_prep_0 + 120
	5   OllieApp                            0x000000010c2783de -[FIRDocumentSnapshot dataWithServerTimestampBehavior:] + 238
	6   OllieApp                            0x000000010c2782df -[FIRDocumentSnapshot data] + 47
	7   OllieApp                            0x000000010ca82911 +[RNFirebaseFirestoreDocumentReference snapshotToDictionary:] + 305
	8   OllieApp                            0x000000010ca816b7 __62-[RNFirebaseFirestoreDocumentReference get:resolver:rejecter:]_block_invoke + 151
	9   OllieApp                            0x000000010c2d3883 __59-[FSTFirestoreClient getDocumentFromLocalCache:completion:]_block_invoke + 499
	10  OllieApp                            0x000000010c2b3504 _ZZ34-[FSTDispatchQueue dispatchAsync:]ENK3$_1clEv + 36
	11  OllieApp                            0x000000010c2b34cd _ZNSt3__128__invoke_void_return_wrapperIvE6__callIJRZ34-[FSTDispatchQueue dispatchAsync:]E3$_1EEEvDpOT_ + 45
	12  OllieApp                            0x000000010c2b3299 _ZNSt3__110__function6__funcIZ34-[FSTDispatchQueue dispatchAsync:]E3$_1NS_9allocatorIS2_EEFvvEEclEv + 41
	13  OllieApp                            0x000000010c2b0c8b _ZNKSt3__18functionIFvvEEclEv + 123
	14  OllieApp                            0x000000010c24d27c _ZN8firebase9firestore4util10AsyncQueue15ExecuteBlockingERKNSt3__18functionIFvvEEE + 476
	15  OllieApp                            0x000000010c24fc07 _ZZN8firebase9firestore4util10AsyncQueue4WrapERKNSt3__18functionIFvvEEEENK3$_0clEv + 39
	16  OllieApp                            0x000000010c24fbcd _ZNSt3__128__invoke_void_return_wrapperIvE6__callIJRZN8firebase9firestore4util10AsyncQueue4WrapERKNS_8functionIFvvEEEE3$_0EEEvDpOT_ + 45
	17  OllieApp                            0x000000010c24f989 _ZNSt3__110__function6__funcIZN8firebase9firestore4util10AsyncQueue4WrapERKNS_8functionIFvvEEEE3$_0NS_9allocatorISB_EES7_EclEv + 41
	18  OllieApp                            0x000000010c2b0c8b _ZNKSt3__18functionIFvvEEclEv + 123
	19  OllieApp                            0x000000010c25db01 _ZZN8firebase9firestore4util8internal13DispatchAsyncEPU28objcproto17OS_dispatch_queue8NSObjectONSt3__18functionIFvvEEEENK3$_0clEPv + 33
	20  OllieApp                            0x000000010c25dad8 _ZZN8firebase9firestore4util8internal13DispatchAsyncEPU28objcproto17OS_dispatch_queue8NSObjectONSt3__18functionIFvvEEEEN3$_08__invokeEPv + 24
	21  libdispatch.dylib                   0x0000000114bf87ec _dispatch_client_callout + 8
	22  libdispatch.dylib                   0x0000000114c00be5 _dispatch_queue_serial_drain + 1305
	23  libdispatch.dylib                   0x0000000114c014fa _dispatch_queue_invoke + 328
	24  libdispatch.dylib                   0x0000000114bfd344 _dispatch_queue_override_invoke + 726
	25  libdispatch.dylib                   0x0000000114c0436c _dispatch_root_queue_drain + 664
	26  libdispatch.dylib                   0x0000000114c04076 _dispatch_worker_thread3 + 132
	27  libsystem_pthread.dylib             0x000000011511d1ca _pthread_wqthread + 1387
	28  libsystem_pthread.dylib             0x000000011511cc4d start_wqthread + 13
)

Steps to reproduce:

await firebase.firestore()
    .collection('my-collection')
    .doc('some-doc-id')
    .get({ source: 'server' });

await firebase.firestore()
    .collection('my-collection')
    .doc('some-doc-id')
    .get({ source: 'cache' })

//Native exception thrown...

Environment

IOS
macOS Sierra
RN 54
RN FIrebase 4.3.5

Using Firestore 5.4.1 in my Podfile, which is super bleeding edge. I don't think that's the source of the problem though, since after looking at the google change logs, the only changes to Firestore since 5.3.0 (the version officially supported by RN Firebase) have been either internal improvements or bugfixes.

Not using Typescript.

[Ehesp]

Thanks for the report, will get this checked out. Can you easily replicate on Android to help debug?

Cheers

[scottmas]

To give some more detail, it only appears to happen for SOME documents. I haven't been able to figure out why some collections are borked and others aren't. Maybe a permission rules thing?

I haven't quite upgraded Android to the latest Firebase version, so let me do that and then get back to you if I can replicate it there.

[Ehesp]

Ok cheers - anything to fully replicate it every time would be super handy!

[scottmas]

Geez luis... It appears to be dependent on the local data being in a weird state. After I wiped my ios device, the issue goes away.

I don't understand how you guys do error catching, but at the very least wouldn't we expect RN Firebase to throw a JS error instead of blowing up on the native thread.

[Ehesp]

It should be thrown as a JS promise error into the catch, see: https://github.com/invertase/react-native-firebase/blob/master/ios/RNFirebase/firestore/RNFirebaseFirestoreDocumentReference.m#L50

If you do the following, does it catch it JS side?

try {
  await firebase.firestore()
      .collection('my-collection')
      .doc('some-doc-id')
      .get({ source: 'cache' })
} catch (e) {
  console.error(e);
}

[scottmas]

No, it doesn't. It only gets caught at the native level and makes the entire app crash.

[Ehesp]

Right interesting, it could be an iOS native bug which is crashing in their code as it's not handled.

When you say "It appears to be dependent on the local data being in a weird state", how exactly did you get it into the 'weird' state?

[scottmas]

I don't know. It may have something to do with the recent 5.4.1 fix which healed a bug in Firestore of corrupted caches.

So probably best to take this to the Firestore IOS SDK repo?

[Ehesp]

Potentially, maybe @Salakar has some idea before taking it up with Firebase... pingy ping.

[Ehesp]

@scottmas in fact, could you try ensuring the 5.4.1 is installed and see if you can replicate?

There has been a few big bugs with 5.3.0, and we've also had some cache issues reported on Discord with that version

[scottmas]

Yes, 5.4.1 is installed.

From my Podfile.lock

- Firebase/Auth (5.4.1):
    - Firebase/CoreOnly
    - FirebaseAuth (= 5.0.2)
  - Firebase/Core (5.4.1):
    - Firebase/CoreOnly
    - FirebaseAnalytics (= 5.0.1)
  - Firebase/CoreOnly (5.4.1):
    - FirebaseCore (= 5.0.6)
  - Firebase/Firestore (5.4.1):
    - Firebase/CoreOnly
    - FirebaseFirestore (= 0.12.6)

[Ehesp]

Yep it's a firebase issue then. Just had a quick chat with @Salakar and he agreed it should be raised on their side. The stack trace also points to it being internal to firebase.