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

Allow applications to handle CloudKit zone purges before local deletion

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

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
38/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
sqlite, swift
Área
databases, distributed-systems

Línea de trabajo

Start in Sources/SQLiteData/CloudKit/SyncEngine.swift at handleFetchedDatabaseChanges, especially the .deleted and .purged path, and compare it with the .encryptedDataReset handling. Read Tests/SQLiteDataTests/CloudKitTests/FetchedDatabaseChangesTests.swift for the existing deletion and preservation expectations. Done should define and test an application policy or delegate point for private-zone purges while preserving the current default behavior.

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

Descripción

Description

Could SyncEngine expose an application policy/delegate hook before deleting local records in response to a CloudKit zone purge?

In ReceiptGenie, the local receipt library is durable user data. If a user removes the app's cloud data to free iCloud storage, we would like to preserve their local library and pause cloud synchronization, then let them explicitly choose whether to resume/re-upload or delete their local data. We do not want to silently recreate the cloud contents against the user's intent either.

This is a source-based behavior/API report, not a claim that SQLiteData caused a confirmed customer incident. We are getting reports from production customers about missing local records and investigating, but do not have the customer's CloudKit event history or a confirmed triggering action.

Current behavior in the source

In SyncEngine.swift at 1.12.0, handleFetchedDatabaseChanges handles .deleted and .purged together by deleting local rows associated with the zone through SyncMetadata. It then schedules recreation of the default zone. .encryptedDataReset instead takes the upload path.

I found the same policy in 1.6.1. Account changes already have an application delegate hook, but I could not find an equivalent interception point for zone purges.

The existing FetchedDatabaseChangesTests document local deletion after zone deletion and preservation after encrypted-data reset. I inspected these tests; I have not run a real iCloud-storage-purge reproduction or the upstream test suite for this report.

Requested behavior / questions
  • Is propagating a .purged zone event into local row deletion the intended product contract?
  • Is there a supported way to preserve the local library and pause synchronization on that event today?
  • Would you consider a reason-aware delegate/policy hook before local deletion, allowing an app to choose its recovery flow while preserving the existing default for other apps?

The request concerns the app's private database zone. It is not a proposal to ignore ordinary receipt deletion on another device or retain access to revoked shared records. Account switching also needs its own isolation policy so one account's data is never uploaded to another.

Reproduction status / versions

Source inspected: SQLiteData 1.6.1 and 1.12.0. No standalone runtime reproducer yet; customer app version and triggering event remain unknown. This report is deliberately scoped to the identifiable source behavior and the missing application policy hook. Happy for this to be moved to Discussions if that is the preferred venue.

Lenguaje dominante
Swift
Estrellas
1.9k
Forks
154
Merge medio
2 d 18 h
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.