fix(push): re-register the device token on opt-in (#675) - #689
Merged
Conversation
Contributor
posthog-android Compliance ReportDate: 2026-08-11 10:58:50 UTC ✅ All Tests Passed!46/46 tests passed Capture Tests✅ 29/29 tests passed View Details
Feature_Flags Tests✅ 17/17 tests passed View Details
|
Contributor
Prompt To Fix All With AI### Issue 1
posthog/src/main/java/com/posthog/PostHogIntegration.kt:39
**Breaks integration interface compatibility**
When a Java consumer upgrades with a custom `PostHogIntegration`, the new method is abstract in the generated JVM interface, causing source compilation failures; previously compiled implementations encounter `AbstractMethodError` when `optIn()` dispatches the method and therefore miss the lifecycle notification.
### Issue 2
posthog/src/main/java/com/posthog/PostHog.kt:1106
**Logger failure escapes dispatch**
When a custom integration and the configured logger both throw, this direct logging call lets the secondary exception escape `optIn()` and prevents later integrations from receiving the notification; use the existing non-throwing `safeLog` helper here.
```suggestion
safeLog("Failed to notify integration of opt-in: $e.")
```
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "chore: record onOptIn in posthog-android..." | Re-trigger Greptile |
marandaneto
reviewed
Aug 10, 2026
…gIntegration compatible (#675)
Contributor
🦔 ReviewHog reviewed this pull requestFound 0 must fix, 2 should fix, 2 consider. Published 4 findings (view the review). |
Contributor
|
ReviewHog Alpha 🦔 If you find any issues helpful - please reply "valid", "invalid", etc., for evaluation purposes 🙏 |
Contributor
There was a problem hiding this comment.
ReviewHog Report
Changes
Issues: 4 issues
Files (5)
.changeset/push-optin-reregister.mdposthog-android/src/main/java/com/posthog/android/internal/PostHogPushSubscriptionIntegration.ktposthog/api/posthog.apiposthog/src/main/java/com/posthog/PostHog.ktposthog/src/main/java/com/posthog/PostHogOptInReceiver.kt
…tegration in the opt-in log (#675)
…ion point in changeset
marandaneto
approved these changes
Aug 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The opt-in half of #675. After a logout
unregisterPushNotificationToken()clears the stored device token,optIn()only flips consent back on. It never refetches the FCM token or re-registers the device, so a user who opts out and back in stays unsubscribed and Workflows can't target them until the next app launch re-runs registration (oronNewTokenhappens to fire).Change
Adds an
onOptIn()lifecycle hook toPostHogIntegration(default no-op).PostHog.optIn()now notifies every integration, mirroring howonRemoteConfigis dispatched.PostHogPushSubscriptionIntegration.onOptIn()refetches the FCM token and re-registers the device, reusing the same executor and token fetcher as install.The push integration is only registered when
capturePushNotificationSubscriptionsis enabled, so the refetch is gated to auto-capture apps. Manual push mode is unchanged: the host owns the token lifecycle.How tested
onOptInrefetches the token and re-registers the device (a second registration after install), inPostHogPushSubscriptionIntegrationTest.adb reverseto the backend). The app auto-registered its FCM token on launch, opt out cleared it, then opt in refetched the FCM token and re-registered the device (POST /api/push_subscriptions, 200). Rebuilt with the opt-in dispatch disabled and the same opt-in produced no re-register.Not in this PR
The strand-the-unregister-DELETE half of #675 is fixed separately in #688. This PR is independent and targets
main.Note
Draft. Directed by @dmarchuk; implemented and verified locally by Claude while @ioannisj is out.