v10.45.0

Enhancements

• Update release packaging for Xcode 15.1.
• Expose waiting for upload/download on SyncSession, which will suspend the current method (or call an asynchronous block) until an upload or download completes for a given sync session, e.g.,:

  try realm.write {
    realm.add(Person())
  }
  try await realm.syncSession?.wait(for: .upload)

  Note that this should not generally be used– sync is eventually consistent and should be used as such. However, there are special cases (notably in testing) where this may be used.
• Sync subscription change notifications are now cancelled if the sync session becomes inactive as is done for upload and download progress handlers. If a fatal sync error occurs it will be reported to the completion handler, and if the user is logged out an "operation cancelled" error will be reported. Non-fatal errors are unchanged (i.e. the sync client internally retries without reporting errors). Previously fatal errors would result in the completion handler never being called. (Core #7073)
• Automatic client reset recovery now preserves the original division of changesets, rather than combining all unsynchronized changes into a single changeset. This will typically improve server-side performance when there are a large number of recovered changes (Core #7161).
• Automatic client reset recovery now does a better job of recovering changes when changesets were downloaded from the server after the unuploaded local changes were committed. If the local Realm happened to be fully up to date with the server prior to the client reset, automatic recovery should now always produce exactly the same state as if no client reset was involved (Core #7161).

Fixed

• Flexible sync subscriptions would sometimes not be sent to the server if they were created while the client was downloading the bootstrap state for a previous subscription change and the bootstrap did not complete successfully. (Core #7077, since v10.21.1)
• Flexible sync subscriptions would sometimes not be sent to the server if an UPLOAD message was sent immediately after the subscription was created. (Core #7076, since v10.43.1)
• Creating or removing flexible sync subscriptions while a client reset with automatic recovery enabled was being processed in the background would occasionally crash with a KeyNotFound exception. (Core #7090, since v10.28.2)
• Automatic client reset recovery would sometimes fail with the error "Invalid schema change (UPLOAD): cannot process AddColumn instruction for non-existent table" when recovering schema changes while made offline. This would only occur if the server is using the recently introduced option to allow breaking schema changes in developer mode. (Core #7042).
• MutableSet<String>.formIntersection() would sometimes cause a use-after-free if asked to intersect a set with itself (since v10.0.0).
• Errors encountered while reapplying local changes for client reset recovery on partition-based sync Realms would result in the client reset attempt not being recorded, possibly resulting in an endless loop of attempting and failing to automatically recover the client reset. Flexible sync and errors from the server after completing the local recovery were handled correctly (Core #7149, since v10.0.0).
• During a client reset with recovery when recovering a move or set operation on a List<Object> or List<AnyRealmValue> that operated on indices that were not also added in the recovery, links to an object which had been deleted by another client while offline would be recreated by the recovering client, but the objects of these links would only have the primary key populated and all other fields would be default values. Now, instead of creating these zombie objects, the lists being recovered skip such deleted links. (Core #7112, since client reset recovery was implemented in v10.25.0).
• During a client reset recovery a Set of links could be missing items, or an exception could be thrown that prevents recovery (e.g. "Requested index 1 calling get() on set 'source.collection' when max is 0") (Core #7112, since client reset recovery was implemented in v10.25.0).
• Calling sort() or distinct() on a MutableSet<Object> that had unresolved links in it (i.e. objects which had been deleted by a different sync client) would produce a Results with duplicate entries.
• Automatic client reset recovery would duplicate insertions in a list when recovering a write which made an unrecoverable change to a list (i.e. modifying or deleting a pre-existing entry), followed by a subscription change, followed by a write which added an entry to the list (Core #7155, since the introduction of automatic client reset recovery for flexible sync).
• Fixed several causes of "decryption failed" exceptions that could happen when opening multiple encrypted Realm files in the same process while using Realms stored on an exFAT file system. (Core #7156, since v1.0.0)
• Fixed deadlock which occurred when accessing the current user from the App from within a callback from the User listener (Core #7183, since v10.42.0)
• Having a class name of length 57 would make client reset crash as a limit of 56 was wrongly enforced (57 is the correct limit) (Core #7176, since v10.0.0)
• Automatic client reset recovery on flexible sync Realms would apply recovered changes in multiple write transactions, releasing the write lock in between. This had several observable negative effects:
  • Other threads reading from the Realm while a client reset was in progress could observe invalid mid-reset state.
  • Other threads could potentially write in the middle of a client reset, resulting in history diverging from the server.
  • The change notifications produced by client resets were not minimal and would report that some things changed which actually didn't.
  • All pending subscriptions were marked as Superseded and then recreating, resulting in anything waiting for subscriptions to complete firing early.
    (Core #7161, since v10.29.0).
• If the very first open of a flexible sync Realm triggered a client reset, the configuration had an initial subscriptions callback, both before and after reset callbacks, and the initial subscription callback began a read transaction without ending it (which is normally going to be the case), opening the frozen Realm for the after reset callback would trigger a BadVersion exception (Core #7161, since v10.29.0).

Compatibility

• Realm Studio: 14.0.1 or later.
• APIs are backwards compatible with all previous releases in the 10.x.y series.
• Carthage release for Swift is built with Xcode 15.1.0.
• CocoaPods: 1.10 or later.
• Xcode: 14.1-15.1.0.

Internal

• Migrated our current CI Pipelines to Xcode Cloud.
• Upgraded realm-core from 13.23.1 to 13.24.1