Quick follow-up on point #2 (Security Roles): checked Schema → Security Roles. GuardianRequest and GuardianResponse grant Read via _world, Create via _icloud, Write via _creator — a standard public-DB config. The Read permission query subscriptions need is present, so Security Roles don't appear to be the cause.

Hi Ziqiao, thank you, both suggestions were worth testing. Unfortunately neither resolves it. Reporting back with results and fresh request IDs you can correlate server-side. Setup: container iCloud.com.luiz.PandaApp, PUBLIC database. Two CKQuerySubscriptions, options: [.firesOnRecordCreation], simple equality predicates (guardianRecordName == %@, requesterRecordName == %@). Visible NotificationInfo (your point #3). Set alertBody, shouldBadge = true, and category; did not set shouldSendContentAvailable. Subscription save still fails: CKError code 12; CKInternalErrorDomain 2006 "BadSyntax"; ServerErrorDescription: "attempting to create a subscription in a production container." Server log: RequestUUID 9BD2E50A-60DF-4DDA-86EF-B91E27192F33 (Op 46EA29B4FF3AFC28), SubscriptionCreate / PUBLIC / USER_ERROR / BAD_REQUEST, ~65–82 ms (20 May 2026 ~15:07 UTC). 2) CKModifySubscriptionsOperation instead of CKDatabase.save(_:). Same failure: Server logs (21 May 2026 ~04:12 UTC): RequestUUID 3276D248-EBCA-4D33-8C47-9E491AD249F3 (Op FCC08756EB6CA504) and RequestUUID 33D892A3-480B-48BE-8935-F7149FB2F622 (Op 92294938173AE34D), both SubscriptionCreate / PUBLIC / USER_ERROR / BAD_REQUEST. (Note: the per-subscription error surfaces via perSubscriptionSaveBlock; the overall modifySubscriptionsResultBlock reported success, so the client looked successful while the server rejected the save.) Additional facts: An earlier test with NSPredicate(value: true) failed with the identical error — so it isn't the predicate. CKRecord saves to this same PUBLIC database succeed routinely (we create GuardianRequest/GuardianResponse records); only SubscriptionCreate fails — so this isn't iCloud sign-in or record-level write permission. Reproduced on iOS 26.4.x and on a second Apple ID on iOS 18.6.x, so it's distinct from the iOS 26.4 silent-push regression (Thread 820562). Re point #2: I reviewed Schema → Security Roles — [FILL IN what you found]. Predicate, NotificationInfo (silent and visible), and the save API have all been varied with no change; the rejection is identical at the gateway. Questions: (1) Is this the known CKError 12 / "production container" server-side issue? (2) Is there a server-side remediation or a CloudKit Console action on our side (re-deploy schema, Security Roles change) that would unblock SubscriptionCreate for this container's PUBLIC database? (3) If a server-side fix is required, should I file a TSI/Feedback referencing these RequestUUIDs? Thank you!