You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 7, 2026. It is now read-only.
I noticed that cancelTriggerNotifications sometimes returns before the scheduled notifications are removed from the database. So far I only noticed it on Android.
In the test below, the number of scheduled notification is not always zero after notifee.cancelTriggerNotifications returned.
awaitnotifee.cancelTriggerNotifications()console.log('number of scheduled notification:',(awaitnotifee.getTriggerNotifications()).length)// not always 0
In our app, we cancel all notifications before scheduling a new one. The issue cases a race condition. Sometimes the first few notifications we scheduled are removed unexpectedly by the ongoing cancelTriggerNotifications. The example below shows what we are doing.
awaitnotifee.cancelTriggerNotifications()awaitnotifee.createTriggerNotification(...)// this notification could be removed
I looked into the native code, do you think this might be the issue that the deletion occurs in the onSuccess callback?
Hi,
I noticed that
cancelTriggerNotificationssometimes returns before the scheduled notifications are removed from the database. So far I only noticed it on Android.In the test below, the number of scheduled notification is not always zero after
notifee.cancelTriggerNotificationsreturned.In our app, we cancel all notifications before scheduling a new one. The issue cases a race condition. Sometimes the first few notifications we scheduled are removed unexpectedly by the ongoing
cancelTriggerNotifications. The example below shows what we are doing.I looked into the native code, do you think this might be the issue that the deletion occurs in the
onSuccesscallback?notifee/android/src/main/java/app/notifee/core/NotificationManager.java
Line 477 in 685cdc3
Many thanks,
Yupeng