Skip to content

Handle 'quotaExceeded' errors - #335

Merged
mbrandonw merged 3 commits into
mainfrom
quota-exceeded
Nov 4, 2026
Merged

mbrandonw merged 3 commits into
mainfrom
quota-exceeded

Conversation

@mbrandonw

@mbrandonw mbrandonw commented Dec 18, 2025 •

Copy link
Copy Markdown
Member

If the user runs out of iCloud storage, saving records will report a .quotaExceeded error. Currently we are not handling that error correctly. Those updates will never be retried again later (unless the record happens to be edited later). And there is currently no way for the user of our library to be notified of such errors so that they can let the user know that there is something for them to fix. This PR addresses both of those problems:

  • When we detect a .quotaExceeded error we not save the record ID to the PendingRecordZoneChanges table, which means they will be re-enqueued whenever the sync engine starts again. This will give the records a chance to save again at a later time.
    • Related to this, we also now retry those records if the sendChanges method is every explicitly called on the sync engine.
  • Added a new delegate method that allows listening for when saving records caused a .quoteExceeded error.

Fixes #548, #547

Comment on lines +95 to +96
/// This method can be called many times, and so you will want to de-duplicate the
/// `quotaExceeded` boolean so as to not alert your users multiple times.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should also have a quotaExceeded: Bool observable value on the SyncEngine? That would allow showing/hiding a banner in the UI.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be very handy!

@mbrandonw
mbrandonw marked this pull request as draft December 19, 2025 16:42
@mbrandonw

Copy link
Copy Markdown
Member Author

I'm converting this to a draft because currently I'm not entirely sure how we can be notified of quotaExceeded errors from CKSyncEngine. Looking into it more...

Comment on lines +102 to +106
func syncEngine(
_ syncEngine: SyncEngine,
quotaExceeded: Bool,
scope: CKDatabase.Scope
)

@mbrandonw mbrandonw Dec 19, 2025 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we surface the record/participant/CKShare that is responsible for the error?

pfriesch added a commit to pfriesch/sqlite-data that referenced this pull request Oct 4, 2026
@mbrandonw
mbrandonw marked this pull request as ready for review November 3, 2026 20:58
@mbrandonw
mbrandonw merged commit 567ff29 into main Nov 4, 2026
5 checks passed
@mbrandonw
mbrandonw deleted the quota-exceeded branch November 4, 2026 17:28
mario-luis-dev added a commit to mario-luis-dev/sqlite-data that referenced this pull request Nov 9, 2026
Brings in what upstream merged after 1.12.1, unreleased: the upload sort
(pointfreeco#571), quotaExceeded saves parked and sent again (pointfreeco#335, pointfreeco#576), cached
records waiting for their parent (pointfreeco#567), CloudKit rate limiting (pointfreeco#569, pointfreeco#564),
the mock database's modification dates (pointfreeco#574) and the @fetch load race
(pointfreeco#536).

Conflicts, resolved:
- Upload sort: upstream's topologicallyAscending replaces the fork's own
  comparator; the fork's reference violation guard stays.
- enqueueLocallyPendingChanges takes upstream's scope, and still reads,
  queues and removes the queued notes in one write, so a note written while
  sync starts is queued exactly once. Notes written while sync is stopped
  record their database, as upstream's do.
- MockSyncEngineState takes upstream's single State, and keeps the fork's
  hook before adding changes and its rule that only the last save or
  deletion of a record stays queued.
- MockCloudDatabase takes upstream's records(for:) and keeps the fork's
  recordsLookupError and deletionLog.

The fork's own server lookups (settleDependents, the lost deletion and
leftover record checks) go through upstream's batched records(for:), so
they wait and try again when CloudKit limits the request rate.

Tests: MyDelegate is upstream's AccountChangedDelegate now; a share's
snapshot shows cloudkit.title as in upstream's; PreviewTests.delete() waits
for the preview timer's send to return before it ends (the fork's sends do
more after the server changes, and the test ended while one was still
returning in 4 of 5 full runs). Full suite: 421 pass, 6 runs in a row.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants