After some discussion, we're okay considering that if CDS is down, all
of Signal is down. This will help protect session state and reduce the
risk of divergence.
Also changed the FeatureFlag guarding this code to
useOnlyModernContactDiscovery.
- Removed static UUIDBackfillTask initializer and removed the
registration from AppDelegate. Kicking off the task will be handled
with IOS-631.
- Moved the async perform work to its own function
- Some minor syntactic changes
- Updated database fetch to retrieve empty string UUIDs
- Handles non-e164 numbers fetched from database
- Leverages the MockSSKEnvironment to deal with the shared
SignalServiceAddressCache. Removes added test support.
- Add tests to exercise new functionality
This adds a whole bunch of tests for UUIDBackfillTask. This required a
small change to be made in SignalServiceAddress. Currently,
SignalServiceAddress accesses a singleton cache to force updates to any
existing addresses after a UUID is discovered. This breaks a whole bunch
of test verification.
To workaround this, I've added a testing_ flag to modify the singleton
SignalServiceAddressCache to temporarily disable it. This is going to
cause problems if we ever enable test parallelization, but it's all we
can do for now.
This also adds in incremental backoff logic, changes some of the log
statements and disables the task on production.
Also, adopted some minor feedback Matthew provided in the draft PR,
including:
- Rename: {signal -> registered}RecipientsWithoutUUID
- Move to owsFailDebug instead of assertionFailure
- Adopt `IsNetworkConnectivityFailure` for discerning network failures
- Add some extra assertions around our registered/unregistered sets
This commit adds two new synchronization utilities:
- Unfair locks: This adds an Objective-C wrapper around os_unfair_lock
to help bridge it to Swift. (Swift's handling of the underlying C
struct can lead to surprising TSan failures). This will be useful as a
simple, performant lock in cases where fairness is not a concern.
- Shared serial queues: Private serial queues that are untargeted will
target the global concurrent queues. Sometimes this is what we want,
especially for potentially long-running work items. But for cases
where work items are brief private serial queues risk spinning up a
new thread.
For private queues where the individual work items are brief and there
isn't a more appropriate queue to target, the shared serial queues
are a potential candidate.
This change also introduces tests for these new utilities and some QoS
management helper methods.
