Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
#563 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
sqlite, swift

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Swift
Star
1.9k
Fork
157
Merge trung bình
3 phút
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pointfreeco/sqlite-data

Tất cả issue của pointfreeco/sqlite-data

Issue tương tự

Thêm issue về Swift

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.