Move FirestoreInternalError to firebase::firestore to match
FirestoreException in Android.
When importing this into google3, we'll have to delete the
Android-specific version of this type.
Any non-zero heartbeat value is immediately reset to zero upon retrieval. Thus, should the network request containing the heartbeat value and the user agent string fail, the previous logic would prevent us from sending the user agent string until the next day (when the heartbeat once again returns a non-zero value). Until this is resolved, always send the user agent string, regardless of the heartbeat value. The associated increase in bandwidth usage is minor (~1.2% in _total_ traffic from running the full suite of Firestore integration tests, which represent the worst-case scenario because they recreate the streams much more often than a typical application).
* update nanopb from 0.3.9.5 to 0.3.9.6
This fixes issues building firestore SDK with Python3.
Interestingly, latest version 0.4.2 still errors during the build
but 0.3.9.6 works. The git commit for this fix in nanopb
https://github.com/nanopb/nanopb/commit/63f8e5e4946a5f8f0211b454bd37187871c3d023
* Update generated sources
* updating just nanopb dependency version
nanopb updated from 0.3.9.5 to 0.3.9.6
(pod version 1.30905.0 to 1.30906.0)
* Add missing source specifier
* Generated files for protos using nanopb 0.3.9.6
* removed unnecessary whitespaces in files generated by protoc
* using more qualified relative paths for header includes
* Changelog
Co-authored-by: Marek Gilbert <mcg@google.com>
Co-authored-by: Paul Beusterien <paulbeusterien@google.com>
* Remove the extension that makes NSDate ServerTimestampWrappable.
This turns out not to actually work because NSDate does not conform to
Codable. Users can supply their own extensions that make NSDate conform
to Codable and also supply an extension like this one to make NSDate
conform to ServerTimestampWrappable.
Add a test that verifies ServerTimestamps of Dates actually work. The
equivalent test for NSDate does not compile.
* Fix minimum Swift version for FirebaseFirestoreSwift
FirebaseFirestoreSwift was already using synthesized Equatable and
Hashable conformance which requires Swift 4.1.
* Add conditional conformance to Hashable to Firestore property wrapper types
Mark these types as conforming to Hashable if the underlying type itself
conforms to hashable. This implementation relies on synthesized
Equatable and Hashable conformance that shipped as a part of Swift 4.1.
* Fix lint/style
* Changelog
This turns out not to actually work because NSDate does not conform to
Codable. Users can supply their own extensions that make NSDate conform
to Codable and also supply an extension like this one to make NSDate
conform to ServerTimestampWrappable.
Add a test that verifies ServerTimestamps of Dates actually work. The
equivalent test for NSDate does not compile.
Swift Package Manager does not support configure-time feature testing
and does not support source transformations of any kind so we can't
cheat by running a sed command to generate config.h before building.
This change makes it so that CMake now generates a config_detected.h
while config.h always exists and contains fallback values if the build
system cannot generate config_detected.h.
Convert CocoaPods to use the same fallbacks since the values are the
same as SPM.
* Add the ability to await a single expectation
* Await individual expectations in test helpers
This prevents tests from accidentally awaiting unrelated expectations
when using the helpers.
* Fix tests that implicitly relied on test helpers to await all
* Add a test that verifies ListenerRegistration::Remove blocks
* Block ListenerRegistration::Remove when there are outstanding callbacks.
* Test that remove does not block when called from the callback.
* Avoid deadlock during shutdown on Linux/Windows
Under some circumstances, the Executor can be accessed by a user task
that's running during shutdown.
* Fix running with HAVE_LIBDISPATCH=0 on macOS
TSAN uncovered cases where we were reading values in the transaction
thread that were set on the main thread and were unprotected by lock. In
practice this is unlikely to cause an harm, but it's good to keep TSAN
clean for when there are real issues.
Paul Beusterien