Summary
The app registers every install for push notifications with the Bitkit notification server, including E2E builds whose device is wiped minutes later. Each wiped install leaves a dead FCM token that the LSP keeps pushing to.
Scope
- Cross-platform: same behavior on Android and iOS, one issue per repo (counterpart linked below).
- Requested change: E2E builds skip the network registration with the notification server and log one line, keyed on the existing
E2E build flag. Every other build keeps today's behavior.
- Out of scope: how the notification server handles dead tokens (synonymdev/bitkit-notification-server#19), and Blocktank's retry loop.
Observed on staging
On 2026-09-10 the Blocktank staging ln2 watcher logged 210 Failed to notify peer … Notification reject by Apple/Google errors for 5 node ids, all E2E wallets. WakeToTimeoutWatcher retries an offline peer with a pending HTLC every 5 minutes for up to 14 days, and a provider reject does not stop it. No E2E spec exercises push notifications, so registration from those builds serves nothing.
Why E2E builds can skip it
No E2E test uses push notifications: grep -ri notification bitkit-e2e-tests/test/specs finds nothing. The suite drives the app in the foreground, and receiving a payment while backgrounded is never asserted, so a registration from an E2E build is never consumed. The only effect of registering is the dead token the wiped device leaves behind, which Blocktank then retries against every 5 minutes for up to 14 days.
Mechanism
LspNotificationsService.registerDevice calls bitkit-core registerDevice against Env.blocktankNotificationApiUrl unconditionally and caches the token in the keychain.
- Callers:
LightningRepo.registerForNotifications on node start, FcmService.onNewToken, and the DevSettings manual action.
E2E=true is already set on exactly the builds that matter: the E2E APK steps in .github/workflows/e2e.yml and e2e_migration.yml, and just e2e. ci.yml and ui-tests never launch the app on a device; release builds never set it.
Fix
LightningRepo.registerForNotifications returns early with a single Logger.info line when Env.isE2eTest is set. All three callers go through it, so they skip together. FCM token retrieval, the keychain cache, and receive-side handling in FcmService are not reached and stay untouched.
- The Dev Settings manual action toasts
Skipped push registration in E2E builds.
- No new flag, no Gradle or workflow change.
Verification
E2E=true build → create wallet → node start logs the skip line and no Registering device for notifications….
- Default build → node start proceeds to registration as before.
- Existing lint and unit tests pass.
- Staging: after the E2E APK carries the change, no new node ids appear in the
WakeToTimeout reject lines.
Counterpart: synonymdev/bitkit-ios#739.
Summary
The app registers every install for push notifications with the Bitkit notification server, including E2E builds whose device is wiped minutes later. Each wiped install leaves a dead FCM token that the LSP keeps pushing to.
Scope
E2Ebuild flag. Every other build keeps today's behavior.Observed on staging
On 2026-09-10 the Blocktank staging ln2 watcher logged 210
Failed to notify peer … Notification reject by Apple/Googleerrors for 5 node ids, all E2E wallets.WakeToTimeoutWatcherretries an offline peer with a pending HTLC every 5 minutes for up to 14 days, and a provider reject does not stop it. No E2E spec exercises push notifications, so registration from those builds serves nothing.Why E2E builds can skip it
No E2E test uses push notifications:
grep -ri notification bitkit-e2e-tests/test/specsfinds nothing. The suite drives the app in the foreground, and receiving a payment while backgrounded is never asserted, so a registration from an E2E build is never consumed. The only effect of registering is the dead token the wiped device leaves behind, which Blocktank then retries against every 5 minutes for up to 14 days.Mechanism
LspNotificationsService.registerDevicecalls bitkit-coreregisterDeviceagainstEnv.blocktankNotificationApiUrlunconditionally and caches the token in the keychain.LightningRepo.registerForNotificationson node start,FcmService.onNewToken, and the DevSettings manual action.E2E=trueis already set on exactly the builds that matter: the E2E APK steps in.github/workflows/e2e.ymlande2e_migration.yml, andjust e2e.ci.ymlandui-testsnever launch the app on a device; release builds never set it.Fix
LightningRepo.registerForNotificationsreturns early with a singleLogger.infoline whenEnv.isE2eTestis set. All three callers go through it, so they skip together. FCM token retrieval, the keychain cache, and receive-side handling inFcmServiceare not reached and stay untouched.Skipped push registrationin E2E builds.Verification
E2E=truebuild → create wallet → node start logs the skip line and noRegistering device for notifications….WakeToTimeoutreject lines.Counterpart: synonymdev/bitkit-ios#739.