Repository navigation
feat(ios): report game reminder lifecycle to Sentry - #1678
EnderOfWorlds007 wants to merge 23 commits into
Conversation
…lemetry-bootstrap
Adds host.reminder.* events through the IssueMonitoring seam (no-op in Release): scheduled / not_scheduled (alarm or notification, with the skip reason), fired (AlarmKit alerting seen while the app runs), tapped and product_opened from the alarm's Play intent, product_opened on the auto-open at the start, missed when the start is reached past the open grace, and cancelled when the product cancels. Each carries the product, the game start and the delay after the start in ms as numbers, plus the host platform, OS version, app version/build and launch id.
|
This pull request touches an app, which is not built by default. Add a label for each build you want:
Each starts as soon as it is added and follows the branch from then on. |
Bundle size reportCompared with
WebAssembly modules
No file changed size. Commit: f0f9db6 |
|
CI Status: not green, 1 item needs attention.
All job results
Signing credentials: valid as of 2026-10-27 Commit |
…elds The alarm's Play button now goes through ProductGameReminderCenter, which drops the held reminder before opening, so a tap is never followed by a second product_opened or by missed. Every event carries logger host.telemetry, and reminder.delivery is set only on scheduled and fired, as on Android. A GameAlarmManaging seam over AlarmManager lets the alarm reminder's scheduled and not_scheduled be tested, alongside the notification reminder's.
| drop(slot.productId) | ||
| if !isLate, !opened { | ||
| if isLate { | ||
| record(.missed, for: slot) |
There was a problem hiding this comment.
Scheduling a start already in the past lands here as missed, same on Android.
| let sentryEvent = Event(level: .info) | ||
| sentryEvent.message = SentryMessage(formatted: event.name) | ||
| sentryEvent.logger = GameReminderEvent.logger | ||
| SentrySDK.capture(event: sentryEvent) { scope in |
There was a problem hiding this comment.
I think we already have proper abstraction in the IssueMonitoring package. For example, one can follow NotificationSlotIssueDiagnostics as an example to add GameReminderDiagnostics. What do you think?
There was a problem hiding this comment.
Done in 15331dd: replaced the dedicated Sentry telemetry type with GameReminderDiagnostics over the shared IssueReporting abstraction, preserving the reminder event fields, fingerprint, level, and no-op behavior.
|
Good call, thanks. We'll rework it as GameReminderDiagnostics following NotificationSlotIssueDiagnostics. |
|
Reworked as you suggested. GameReminderEvent and GameReminderDiagnostics now live in the Products package, following NotificationSlotIssueDiagnostics, and IssueReporting is unchanged. The events go through the HostEvent/HostEventRecording path from #1571, so this PR now depends on #1571. Ready for another look. |
|
Refreshed onto current main (merge, no force-push). The only change beyond the merge is the test recorder adopting the new @autoclosure record() signature. A local iPhone 17 Pro run passes: Debug build, plus the 28 reminder tests and the full suite of 1,540 tests, with 0 failures. Ready for another look. |
What
The iOS host records the full product game-reminder troubleshooting trail:
scheduled,not_scheduled,fired,tapped,product_opened,missed, andcancelled.These are troubleshooting telemetry events, not error reporting.
This PR now depends on #1571 and builds on its
HostEventandHostEventRecordingtypes. Reminder events use that single typed Sentry path instead of adding feature-specific methods to genericIssueReporting.How
GameReminderEventandGameReminderDiagnosticslive in the Products feature package, alongside the product reminder behavior they describe.HostEventValuevalues, including start/delay milliseconds, app build, and whether opening navigated.firedstate. An already-alerting alarm is recorded before refresh can drop its past reminder slot.not_scheduled(start_in_past)event and is not handed to either delivery service.ProductOpenerBoolean return only records whether navigation occurred; it does not route the tap through or mutateProductGameReminderCenter.reminder.open_source:alarmandauto_openare distinct observations around one tap, so both can be present for the same user action.Every reminder event carries the product identifier and canonical host metadata. When available, it also carries the scheduled start, delay from start, delivery, skip reason, open source, app state, and navigation result.
AlarmKit limits
firedis observable only while the app process is running; the synchronous alerting-state check closes the refresh/drop race but cannot reconstruct a ring that happened entirely while the app was absent.stopIntent, which would change Stop behavior and is intentionally out of scope.Verification
Local validation used Xcode 26.6 and an iPhone 17 Pro simulator:
xcodebuild test -scheme Products.GameReminderEventTests,GameReminderDeliveryDiagnosticsTests, andProductGameReminderCenterTestspassed, including fired-before-drop, single past-start, and held-future-reminder replacement regressions.HostEventTestspassed.xcodebuild build -scheme polkadot-app.git diff --checkis clean.Dependency
Depends on #1571. Merge commit
cfade2bd31a0caad499f2f7b2c83a7edc64f29behas the exact #1571 headab88afef3808ac5f47bf3c46dd226dcd3ef1ba43as a parent, so this branch can be reviewed against that parent to isolate the reminder work.