`sendChanges()` / `fetchChanges()`: an error from the private database cancels the shared database, and `syncChanges()` skips fetching when sending fails
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
- Lĩnh vực
- data-engineering, distributed-systems
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 (
mainat 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:
- Use a generic schema:
lists(shareable root) anditems(listID REFERENCES lists(id) ON DELETE CASCADE). - Device A shares a list, and device B accepts the share.
- On device B, insert an item into the shared list and also edit a private (non-shared) record.
- Make the private database's send fail at the request level, then call
try await syncEngine.sendChanges()(orsyncChanges()) 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 assendChanges()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
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của pointfreeco/sqlite-data
-
bug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 56/100
pointfreeco/sqlite-data#561 ·
-
bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 50/100
pointfreeco/sqlite-data#557 · 2 bình luận ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 38/100
pointfreeco/sqlite-data#551 ·
-
Child records deleted locally when their parent's save failed with `quotaExceeded`Có thể đã có người làm @jalalawqati đã nhận 32 ngày trước. Đang mởbug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
pointfreeco/sqlite-data#547 · 3 bình luận · 1 reaction ·
-
CloudKit data loss after deleting then re-inserting record with the same UUIDCó thể đã có người làm @jsutula đã nhận 219 ngày trước. Đang mởbug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
pointfreeco/sqlite-data#418 · 2 bình luận ·
Tất cả issue của pointfreeco/sqlite-data
Issue tương tự
-
agent/sec-check help wanted security stage/010-actionable
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
hivecommons/hotshot#235 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Emanuele-web04/remodex#203 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 92/100
Maintainer thường phản hồi trong vòng 1 ngày
-
test(BrainBar): inject synthetic observabilityCadence in BackupsHealth/one-page fixtures (DCI-1)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
EtanHey/brainlayer#1367 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
omlahore/RemoveMacAI#63 · 1 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày