Skip to content

fix: parallelize push notifications and force high priority (resolves #206) - #215

Merged
abarghoud merged 2 commits into
testingfrom
fix/issue-206-push-latency
Aug 1, 2026
Merged

fix: parallelize push notifications and force high priority (resolves #206)#215
abarghoud merged 2 commits into
testingfrom
fix/issue-206-push-latency

Conversation

@abarghoud

@abarghoud abarghoud commented Jul 31, 2026

Copy link
Copy Markdown
Owner

Resolves #206

Why:

  • Sentry and Break-in alerts were suffering from up to 20-30 minutes delays on iOS and Android for some users because notifications were sent with priority: 'default'. Apple's APNs and Google's FCM delay normal-priority notifications to conserve battery (Doze mode).
  • The alert processing handler was also experiencing artificial latencies because it executed Telegram and Push notifications sequentially, taking over 1000ms combined.
  • The [TELEGRAM_SLOW] telemetry metric incorrectly included the Push API latency, masking the real bottleneck.
  • Frequent normal network fluctuations caused false-positive DELAYED logs due to an overly aggressive 1000ms threshold.

How:

  • Forced priority: 'high' in the Expo Push payload for all notifications to guarantee immediate delivery and wake up sleeping devices.
  • Parallelized the Telegram and Push API calls using Promise.all() in VehicleAlertNotifierService to divide network wait times by two.
  • Isolated the telegramTime measurement to only track the Telegram API call, ensuring accurate metrics.
  • Increased the isProcessingDelayed threshold from 1000ms to 3000ms in vehicle-alert-notifier.service.ts to accommodate normal third-party API latency.
  • Added [EXPO_PUSH_LATENCY] telemetry logs with the correlation ID to trace push API performance.

…206)

Why:
- Sentry and Break-in alerts were suffering from up to 20-30 minutes delays on iOS and Android because notifications were sent with `priority: 'default'`. Apple's APNs and Google's FCM delay normal-priority notifications to conserve battery (Doze mode).
- The alert processing handler was also experiencing artificial latencies because it executed Telegram and Push notifications sequentially, taking over 1000ms combined.
- The `[TELEGRAM_SLOW]` telemetry metric incorrectly included the Push API latency, masking the real bottleneck.
- Frequent normal network fluctuations caused false-positive `DELAYED` logs due to an overly aggressive 1000ms threshold.

How:
- Forced `priority: 'high'` in the Expo Push payload for all notifications to guarantee immediate delivery and wake up sleeping devices.
- Parallelized the Telegram and Push API calls using `Promise.all()` in `VehicleAlertNotifierService` to divide network wait times by two.
- Isolated the `telegramTime` measurement to only track the Telegram API call, ensuring accurate metrics.
- Increased the `isProcessingDelayed` threshold from 1000ms to 3000ms in `vehicle-alert-notifier.service.ts` to accommodate normal third-party API latency.
- Added `[EXPO_PUSH_LATENCY]` telemetry logs with the correlation ID to trace push API performance.
@abarghoud
abarghoud merged commit 076cb96 into testing Aug 1, 2026
3 checks passed
@abarghoud
abarghoud deleted the fix/issue-206-push-latency branch August 1, 2026 18:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants