Symptom
A mobile Sentry issue shows a small burst of identical auth errors (e.g. com.apple.AuthenticationServices.AuthorizationError error 1000), minutes apart, low event count. Easy to stamp as user-cancel noise - a daily triage pass did exactly that.
Recognition
Three tags together identify Apple App Review farm traffic, not users:
- Geo: Cupertino on every event (SDK geo from IP, no PII needed).
- Device-model spread inside one tight window - e.g. iPhone14,6 twice then iPhone17,1 within 7 minutes. Real single-user retries stay on one device.
- Release tag = exactly the build sitting in App Store review (the app was not yet live, so no public installs of that build exist).
Why it matters
Unlike sandbox/crawler noise, review-farm failures on a gated capability (Sign in with Apple, push, IAP) are launch-blocking: App Review tests SIWA per Guideline 4.8 and rejects on failure. Archiving this as noise deletes the only pre-rejection warning you will get.
The code-table trap
AuthorizationError 1000 reads like a user-cancel family but is ASAuthorizationError.unknown; cancel is 1001. Look the platform error code up in its table before inheriting a sibling issue noise verdict - the message text alone (The operation could not be completed) is indistinguishable.
Triage protocol
Do not resolve/archive. Rule out known build-pipeline causes by commit ancestry (in our case the unsigned-archive entitlements-stripping failure was excluded because the fix commit was an ancestor of the build head and the export step hard-fails on missing entitlements), then escalate to whoever owns App Store Connect to read the review messages. Remaining suspects: service-side config (Services ID / domain association) or reviewer iCloud state.