Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Allow applications to handle CloudKit zone purges before local deletion

Aperta
  • Qualcosa non va?
#551 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
38/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
sqlite, swift
Ambito
databases, distributed-systems

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Swift
Stelle
1.9k
Fork
154
Merge medio
2g 18h
PR unite (30g)
1

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pointfreeco/sqlite-data

Tutte le issue di pointfreeco/sqlite-data

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.