Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#563 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
sqlite, swift
Área
data-engineering, distributed-systems

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Swift
Estrellas
1.9k
Forks
157
Merge medio
3 min
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pointfreeco/sqlite-data

Todos los issues de pointfreeco/sqlite-data

Issues similares

Más issues de Swift

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.