These tests fulfill an expectation when a write to the database causes
the desired state to be reached. However, there may still be writes to
the database in flight, and the *next* write will *also* probably be
in the desired state, resulting in the expectation being fulfilled
again. Because this happened *after* the test finished, an exception
was thrown, the test environment terminated, and the *next* test (or
possibly a later one) was being blamed for the failure.
Fix this issue in both places where it happens by allowing multiple
fulfills, and re-enable the test that was previously getting blamed
for this.
UIDatabaseObserver orchestrates notifying views when a transaction commits.
We back UIDatabaseObserver with a DatabaseRegionObserver
DatabaseRegionObservers are not notified if the transaction contains no changes:
https://github.com/groue/GRDB.swift/blob/af0ac15/GRDB/Core/DatabaseRegionObservation.swift#L119
However the more general TransactionObservers *are* notified even if the
transaction contains no changes. Nicely, GRDB does some work to ensure this is
true even in the event of a deferred transaction. See this comment on `databaseDidCommitEmptyDeferredTransaction`
da459386a0/GRDB/Core/TransactionObserver.swift (L444)
ContactAvatarBuilder works with SignalServiceAddress
Currently this only functions with the GRDB adapter. There are other asserts
triggered in yap extensions.
Tests from `receivedEnvelopeData`, which is called by e.g. the websocket or the
messageFetcherJob through the message processing pipeline until the UIDatabase
is notified with the new message and thread.
Includes some test helpers to initialize sessions and encrypt/decrypt messages.
