`sendChanges()` / `fetchChanges()`: an error from the private database cancels the shared database, and `syncChanges()` skips fetching when sending fails

The bug is in Sources/SQLiteData/CloudKit/SyncEngine.swift: the tuple awaits in fetchChanges(_:) and sendChanges(_:), and the early exit in syncChanges(fetchOptions:sendOptions:). Start by reproducing the standalone async let program in the issue to confirm the cancellation. Done means the shared send still completes when the private send throws, the error still reaches the caller, and syncChanges() still fetches after a failed send, shown by tests that inject a failure in one engine.

Description

SyncEngine.sendChanges(_:) and SyncEngine.fetchChanges(_:) start the private and shared CKSyncEngines concurrently with async let, then await them as a tuple:

async let `private`: Void = privateSyncEngine.sendChanges(options)
async let shared: Void = sharedSyncEngine.sendChanges(options)
_ = try await (`private`, shared)

The tuple is awaited left to right. If the private engine throws first, the function exits while shared is still running, and Swift implicitly cancels the remaining async let child task. So one database's failure cancels the other database's work. That work has nothing to do with the failure.

syncChanges(fetchOptions:sendOptions:) has a related problem. It runs try await sendChanges(...) and then try await fetchChanges(...). If sending throws, nothing is fetched.

What we saw in an app that uses SQLiteData with CloudKit sharing: on a participant's device, the private database send failed. Every time, the participant's pending changes to the shared zone came back as cancelled (CKError.operationCancelled), even though nothing was wrong with them. The participant's own edits to the shared list never reached the owner. Pull-to-refresh calls syncChanges(), so the failed send also kept it from fetching the owner's changes.

Environment

• SQLiteData 1.12.1 (main at the time of writing). The code is the same in 1.6.0.
• Xcode 27.0 (27A266a), iOS 27 SDK, device build
• CloudKit sync with sharing enabled (private + shared databases)

Reproduction

The behavior comes from Swift's async let semantics. This standalone program has the same shape as sendChanges:

struct SendFailed: Error {}

func send(_ name: String, fails: Bool) async throws {
  do {
    try await Task.sleep(for: .milliseconds(fails ? 10 : 200))
  } catch {
    print("\(name): \(error)")
    throw error
  }
  if fails { throw SendFailed() }
  print("\(name): finished")
}

func sendBoth() async throws {
  async let `private`: Void = send("private", fails: true)
  async let shared: Void = send("shared", fails: false)
  _ = try await (`private`, shared)
}

Output:

shared: CancellationError()
sendBoth threw SendFailed()

The same thing happens with SQLiteData:

1. Use a generic schema: lists (shareable root) and items (listID REFERENCES lists(id) ON DELETE CASCADE).
2. Device A shares a list, and device B accepts the share.
3. On device B, insert an item into the shared list and also edit a private (non-shared) record.
4. Make the private database's send fail at the request level, then call try await syncEngine.sendChanges() (or syncChanges()) on device B.

Expected behavior

• The shared database sends its pending changes no matter what happens in the private database, and the other way around. The error is still thrown to the caller.
• syncChanges() still fetches remote changes when sending fails.

Actual behavior

• The shared database's in-flight send (or fetch) is cancelled, and its records fail with operationCancelled.
• syncChanges() returns as soon as sendChanges() throws and never fetches.

This only goes one way. If the shared engine throws, the private engine has already been awaited, so the private side is never affected.

Root cause

Sources/SQLiteData/CloudKit/SyncEngine.swift (1.12.1):

• fetchChanges(_:): line 575, _ = try await (private, shared)
• sendChanges(_:): line 597, _ = try await (private, shared)
• syncChanges(fetchOptions:sendOptions:): lines 614–615, where a failed send exits before the fetch

Proposed fix

Await each engine on its own, rethrow the first error once both have finished, and always fetch in syncChanges:

@@ public func fetchChanges(
       async let `private`: Void = privateSyncEngine.fetchChanges(options)
       async let shared: Void = sharedSyncEngine.fetchChanges(options)
-      _ = try await (`private`, shared)
+      var firstError: (any Error)?
+      do { try await `private` } catch { firstError = firstError ?? error }
+      do { try await shared } catch { firstError = firstError ?? error }
+      if let firstError { throw firstError }
     }
@@ public func sendChanges(
       async let `private`: Void = privateSyncEngine.sendChanges(options)
       async let shared: Void = sharedSyncEngine.sendChanges(options)
-      _ = try await (`private`, shared)
+      var firstError: (any Error)?
+      do { try await `private` } catch { firstError = firstError ?? error }
+      do { try await shared } catch { firstError = firstError ?? error }
+      if let firstError { throw firstError }
     }
@@ public func syncChanges(
-      try await sendChanges(sendOptions)
+      var sendError: (any Error)?
+      do { try await sendChanges(sendOptions) } catch { sendError = error }
       try await fetchChanges(fetchOptions)
+      if let sendError { throw sendError }
     }

The public API and error reporting stay the same. The only change is that one database no longer cancels the other. If the caller's task is cancelled, both child tasks are still cancelled as before.

We've been running this patch on top of 1.6.x for a while. I'm happy to open a PR against main with the change and tests, if this approach works for you.